🚀 go-pugleaf

	- hi; in article, <20120917.1210.932816snz@twoplaces.co.uk>,
	 simon@twoplaces.co.uk "Simon Turner" commented & explained:
>	                   "ppint. at pplay" wrote:
>>	(following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
>>	                      in which i wrote):
>> []
>> >	- since some time between wed sep 12 21:33:35 and thu sep 13
>> >	20:07:59 attempting to collect mail from the original base a/c
>> >	(user, wotsit) has repeatedly failed since 20:08:00 after noting
>> >	that the first two emails (always the same two) are one mailkill
>> >	rejected and one to unknown user address (in the scrolling info
>> >	at the net> and in mail.log).
>
>I didn't comment on this before, but it sounds as though you've still
>got "pop3 leave on" -- we need to get to the bottom of this at some
>stage, as it should be off unless you've explicitly turned it on!

	- i <enter>ed "pop3 leave off" from the net> prompt after the
	first time i dialled up after you commented it should default
	to this state, and haven't knowingly changed matters in this
	regard since: which suggests that the "leave off" doesn't get
	carried out until a normal end to the mail-collecting process
	occurs, as opposed to after each individual email is collected
	(or rejected).  bic(oc)bw :-)
>
>> >	- pop3 'top 2 0 failed: ''
>> >	  close pop3-smtp: 0/5 messages (0 old)
>> >
>> >	- pop3 receive failed: reset/refused
>> >	 [this message comes if i close the dial-up connection without
>> >	  having received a 'top M 0 failed: '' & close pop3-smtp: 0/N
>> >	  messages (0 old) message - i've not included repeats of it] 
>
>The fact that you're getting a "TOP M 0 failed" error means (a) that the
>POP3 collection system isn't in a "receiving data" state -- any data
>from the previous message has (apparently) finished coming in -- and (b)
>that it was a TOP command (which only returns the header, not the body)
>that failed, rather than RETR which is used to grab the whole message.

	- hmmm; "interesting..." - especially as up to 6MB of the email
	in question was collected, the last time i tried seeing what
	happened if i just stayed online, in the wee smal hours - and
	had to delete a lock file on the mailbox it was headed for, or
	at least chose to, after i eventually gave up and disconnected.

>>	- a couple of overnight dial-up connections on, i'm no longer
>>	so certain; staying online whilst doing nothing but the occas-
>>	ional "asystat<enter>"/"as<enter>" showed that *something* was
>>	still incoming, every now & then, until the connection dropped.
>
>You can find out whether the POP3-SMTP socket is still receiving data by
>looking up its socket number ("socket"), then running "socket NNN" a
>couple of times and comparing the rcvd totals.

	- ah; yes, i should've thought of that - i've only ever previously
	checked ftp, hop check, ping and similar sessions.
>
>It still looks to me as though something is going wrong, rather than the
>whole thing running normally but taking ages to be received a large
>message.

	- ok; *bows* to greater experience & knowledge of such things :-)
	  (or possibly - but hopefully not - s/rather than/as well as/.)
[]
>The GremNOS POP3 collection picks them up in message order (1, 2, ...),
>which seems to be the order in which the messages arrived in the mailbox;
>size of message doesn't come into it.  (Although it could: see below.)

>>	- cos if not, and someone (or something) sends a ginormous mail
>>	to a live mailbox your domain, then it'll jam things up good'n'
>>	proper, won't it?
>
>Yup, it will.  I hadn't given enough thought to that (having a nice fast
>FTTC connection rather than dialup). 8-(

	- s/8-(/8-0/ ?      - [a]
[>>]
>
>Two improvements spring to mind: (a) modify the POP3 collection to allow
>GremNOS to collect the messages in ascending size order rather than in
>message number order; (b) implement Pete's ESMTP SIZE restrictions for
>POP3 as well, which would allow you to set a size threshold above which
>messages wouldn't be downloaded.

	- will the latter reject messages above the threshold, or leave
	them uncollected?  if the latter, this might trigger the strange
	behaviour seen above, where messages rejected as killfiled/to an
	unknown user-name are actually left on, despite "pop3 leave off"
	being the most recent instruction.      - [b]

[snip A quick POP3 lesson and examples - for both of which, many thanks]
[saved for further study & future reference :-)]

>If you wish to record the session to a file, press F10 to get back to
>the prompt, enter "record pop3.rec" (to record to file POP3.REC) then
>press Enter to return to the session.  Recording will stop when the
>session closes, or when you enter "record off" at the net> prompt.

	- *nods* - except i'll need to remove any & all finger (etc.)
	lines from my autoexec.net when i wish to record pop3 sessions,
	as something doesn't re-set when an smtp session ends - nor,
	when an ftp session ends (which it used to, sort of - formerly,
	it'd re-set to another (the next-highest numbered, iirc) session.
	[or is it properly "socket"?], if any were still live, when
	"<enter>" was typed from net>). (- [c])   - o.k.

	- ?  or possibly, type "s<enter>" to find which "s<0-9><enter>"
	to type to get to the pop3 session - ? (note to self: try it.)

	- love, ppint.

	[a] - may require interpolation of the odd "\"

	[b] - a reasonable response to which might be, "we;ll burn that
	      bridge when we come to it"

	[c] - separate point, & 'ware newsthread crossing with emails

	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
       "The Wikipediasts want to believe that they're working on an
    important project to collect and organize the knowledge of the ages,
  and it offends them if it doesn't (yet) include a detailed history of the
 Napoleonic Wars but does include a complete episode guide to Danger Mouse."
   - Mike Schilling on rasfwr,ff 17:37 GMT 14/6/07 (6/14/07 for merkins)

[This is going to be rather long: apologies in advance.]

On Wednesday, in article
     <20120919.1103.12090207snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120917.1210.932816snz@twoplaces.co.uk>,
>          simon@twoplaces.co.uk "Simon Turner" commented & explained:
> >                          "ppint. at pplay" wrote:
> >>      (following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
> >>                            in which i wrote):
> >> []
> >> >    - since some time between wed sep 12 21:33:35 and thu sep 13
> >> >    20:07:59 attempting to collect mail from the original base a/c
> >> >    (user, wotsit) has repeatedly failed since 20:08:00 after noting
> >> >    that the first two emails (always the same two) are one mailkill
> >> >    rejected and one to unknown user address (in the scrolling info
> >> >    at the net> and in mail.log).
> >
> >I didn't comment on this before, but it sounds as though you've still
> >got "pop3 leave on" -- we need to get to the bottom of this at some
> >stage, as it should be off unless you've explicitly turned it on!
> 
>         - i <enter>ed "pop3 leave off" from the net> prompt after the
>         first time i dialled up after you commented it should default
>         to this state, and haven't knowingly changed matters in this
>         regard since: which suggests that the "leave off" doesn't get
>         carried out until a normal end to the mail-collecting process
>         occurs, as opposed to after each individual email is collected
>         (or rejected).  bic(oc)bw :-)

As noted in d.s, "pop3 leave" is a GremNOS setting: it tells GremNOS
whether (a) to delete messages once they have been received (or
rejected) or (b) leave them on the server.  GremNOS's "pop3 leave" state
is stored in a variable, which is initialised to 0 (i.e. off) at program
start-up: barring internal memory corruption, it can only be changed by
the "pop3 leave on|off" command.

Next time you connect (after reading this 8-), just before you do your
POP3 collection, run "pop3 leave": this will display the current state
of the setting, e.g.

  Leave downloaded mail on server: off

If it's off, that's OK; if not, something is turning it on!  You could
narrow it down by putting "pop3 leave" at the start and end of your
AUTOEXEC.NET file etc.

However, I think I've realised how you could be getting the symptoms of
it being on even though it's really off: see later for details.

BTW, if you're doing your POP3 collections by hand instead of putting
them in AUTOEXEC.NET, I heartily recommend putting them in a file (or
files) that you can later "source" -- that way, you only have to type
the commands in once.  I have an assortment of such 'script' files that
get sourced at regular intervals by the "at" command, and which can also
be run manually e.g. "source pop3dmn.scr".

> >The fact that you're getting a "TOP M 0 failed" error means (a) that the
> >POP3 collection system isn't in a "receiving data" state -- any data
> >from the previous message has (apparently) finished coming in -- and (b)
> >that it was a TOP command (which only returns the header, not the body)
> >that failed, rather than RETR which is used to grab the whole message.
> 
>         - hmmm; "interesting..." - especially as up to 6MB of the email
>         in question was collected, the last time i tried seeing what
>         happened if i just stayed online, in the wee smal hours - and
>         had to delete a lock file on the mailbox it was headed for, or
>         at least chose to, after i eventually gave up and disconnected.

That's very odd.  Did you get any POP3 error messages that time, or did
everything behave normally apart from the download not finishing before
you gave up?

> >You can find out whether the POP3-SMTP socket is still receiving data by
> >looking up its socket number ("socket"), then running "socket NNN" a
> >couple of times and comparing the rcvd totals.
> 
>         - ah; yes, i should've thought of that - i've only ever previously
>         checked ftp, hop check, ping and similar sessions.

It's very useful.  Back when I was using ISDN, I used to get bursts of
packet corruption that could stall an in-progress SMTP send: I got quite
used to using "socket 133" (as it always was) to inspect the socket's
TCP queue and see if it was stalled, waiting for a TCP acknowledgement
that would never come, and if so issuing kicks and/or TCP resets as
appropriate to restart timers or reset the TCP window management.

> >The GremNOS POP3 collection picks them up in message order (1, 2, ...),
> >which seems to be the order in which the messages arrived in the mailbox;
> >size of message doesn't come into it.  (Although it could: see below.)
> 
> >>      - cos if not, and someone (or something) sends a ginormous mail
> >>      to a live mailbox your domain, then it'll jam things up good'n'
> >>      proper, won't it?
> >
> >Yup, it will.  I hadn't given enough thought to that (having a nice fast
> >FTTC connection rather than dialup). 8-(
> 
>         - s/8-(/8-0/ ?      - [a]

8-D

> >Two improvements spring to mind: (a) modify the POP3 collection to allow
> >GremNOS to collect the messages in ascending size order rather than in
> >message number order; (b) implement Pete's ESMTP SIZE restrictions for
> >POP3 as well, which would allow you to set a size threshold above which
> >messages wouldn't be downloaded.
> 
>         - will the latter reject messages above the threshold, or leave
>         them uncollected?

It could (and, I think, should) do either: I can see it being useful for
quick downloads with a low threshold, just to see if that expected (but
short) mail has come in yet, and leave the main download (with a higher
threshold) for later; and the *really* big ones could be left on the
server to be collected at the weekend.

>         if the latter, this might trigger the strange
>         behaviour seen above, where messages rejected as killfiled/to an
>         unknown user-name are actually left on, despite "pop3 leave off"
>         being the most recent instruction.      - [b]

AHA!  The light has just gone on.  Why didn't I think of this before?

A possible (indeed, likely) reason why you kept getting the same
messages left on the server every time you had a problem is that the
POP3 connection was still active (downloading the huge message) when you
disconnected: the server will[*] only process pending deletions when the
client disconnects normally (by sending the QUIT command).  If the QUIT
doesn't appear, the server will eventually time out the connection, and
pending deletions will[*] not be performed -- so the same messages will
be present next time you try.

[*] Or at least should: this is an MS server, so all bets are off wrt
RFC compliance...

One thing I always used to do on dialup just before exiting GremNOS was
a quick "socket", to make sure there weren't any active sockets that
would be broken off mid-stream by the impending disconnection.

Note that noe of this explains the "TOP M 0 failed" errors you saw,
though: those can only have happened due to a real error somewhere (and
they sound very much like loss of synchronisation between server and
client, where GremNOS thinks the server has finished sending but it
actually hasn't, so the next "response" is actually part of the previous
data stream and makes no sense).

I'm going to improve the error messages, which should help work out
what's happening if the problems ever recur; I've checked the code
carefully and can't see how TOP (or a preceding command) could be
failing, so unless it happens again there's not a lot we can do.  (I've
been using POP3 daily for over five years without any problems, except
when Demon ineptly forged the postmaster e-mails and got the *ENV stuff
wrong, and even then I still got the message).

> >If you wish to record the session to a file, press F10 to get back to
> >the prompt, enter "record pop3.rec" (to record to file POP3.REC) then
> >press Enter to return to the session.  Recording will stop when the
> >session closes, or when you enter "record off" at the net> prompt.
> 
>         - *nods* - except i'll need to remove any & all finger (etc.)
>         lines from my autoexec.net when i wish to record pop3 sessions,

No, you shouldn't need to do anything special, since this is a telnet
session you'd be recording, with its own screen; the bit you were having
trouble with previously was trying to record the main command screen,
which is indeed impossible if you've already used F10 to escape back to
it from another session.  (All will become clear below, if you can wade
through that far!)

>         as something doesn't re-set when an smtp session ends

SMTP sending/receiving connections actually don't have their own
sessions -- their status messages get written to the main command
screen.  If you telnet into a server to talk some protocol to it (port
25 for SMTP, 110 for POP3, 119 for NNTP etc.), it's a telnet session.

>         - nor,
>         when an ftp session ends (which it used to, sort of - formerly,
>         it'd re-set to another (the next-highest numbered, iirc) session.

Are you sure KA9Q ever did this (resetting the "active session" marker
to the next-highest-numbered session when the currently active session
ended)?  The GremNOS code certainly doesn't behave that way, although
it's possible to persuade yourself that it does (I managed to persuade
myself thus earlier, before I'd understood how it really works).

The way it works (in plain GremNOS; TextWin versions are a different
matter altogether) is this: there is a concept of the "most recently
escaped from" session, which is the one with a '*' against its number in
the session list: this is the one you return to if you just press Enter,
and is the one recorded by a "record" command.

I'll call this the "last" session to save typing; but the description of
"most recently escaped from" is more accurate.  The last-session marker
is only ever set when you use F10 to escape back from a session to the
main command screen; if you then return to that session and end it,
thereby returning to the main command screen without pressing F10, the
marker -- which was set to that now-defunct session -- is reset to
nothing.  If you do a session list at this point, there is no '*' shown,
pressing Enter doesn't get you anywhere, and attempting to record
anything says "No current session".

Note that, if session 3 (say) has the last-session marker but you return
to session 2 (by entering "session 2") and end that session, thereby
getting back to the main command screen, the marker remains set to
session 3.  This is what I was seeing earlier when I persuaded myself
that it was being updated when a session ended; it wasn't, it was
staying exactly where it had previously been!

The only way to get one of the other sessions to have the last-session
marker is to return to it ("session 4", say) then press F10 to get back
to the main command screen; session 4 now has the last-session marker,
and will the one that gets recorded by the "record" command.

There's certainly an argument to be made that, when the session
currently marked as the "last" one ends, the last-session marker
shouldn't be reset to nothing, but should be reset to one of the other
active sessions (or, failing that, the main command screen -- which is
also technically a "session"); that would IMHO be better than the
current system, and would allow you to record the main command session
if you wanted to (currently you can do it right at the start, because
the last-session marker is initially set to the command session, but it
cannot be got back there if you've ever used F10).

>         [or is it properly "socket"?]

"Sockets" are Internet connections, e.g. between clients and servers.
"Sessions" in KA9Q are discrete 'screens', which can be switched between
by pressing F10 (to get back to the command screen) and entering
"session N".  There can be active sockets without associated sessions
(SMTP, NNTP, POP3-SMTP etc.) and sessions without associated sockets (a
"more" session viewing a local file, a finger that has already ended and
closed its socket etc.)  If a session has an active socket (e.g. an
active ftp or telnet session), the socket number is shown in the "S#"
column in the session list.

>         - ?  or possibly, type "s<enter>" to find which "s<0-9><enter>"
>         to type to get to the pop3 session - ? (note to self: try it.)

That's the one: get back to your POP3 (actually telnet) session, using
"s<enter>" to find out which one it is, then "s N<enter>" to get back to
it; then F10 to escape back to the command screen and update the "most
recently escaped from" marker; then "rec pop3.rec" to record it; <enter>
to return to it; and finally you can start talking to the server.

I told you it was going to be long!

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

	- hi; in article, <20120920.1355.933016snz@twoplaces.co.uk>,
	 simon@twoplaces.co.uk "Simon Turner" pondered & pronounced:
>[This is going to be rather long: apologies in advance.]
[still fairly long...]
>	                  "ppint. at pplay" wrote:
>>	  simon@twoplaces.co.uk "Simon Turner" commented & explained:
>>>	                  "ppint. at pplay" wrote:
>>>>	(following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
>>>>	                     in which i wrote):

[attempting to collect mail from the original base a/c (user, wotsit)
 repeatedly failed after the first two emails (always the same two)
 were mailkill rejected to unknown user address	(in the scrolling info
 at the net> and in mail.log).]
[]
>>>it sounds as though you've still got "pop3 leave on" -- we need to get
>>>to the bottom of this at some stage, as it should be off unless you've
>>>explicitly turned it on!
>>	[..] suggests that the "leave off" doesn't get carried out until
>>	normal end to the mail-collecting process occurs, as opposed to
>>	after each individual email is collected (or rejected).
>>	bic(oc)bw :-)
[]
>"pop3 leave" is a GremNOS setting:

	- ah;
[]
>GremNOS's "pop3 leave" state is stored in a variable, which is initialised
>to 0 (i.e. off) at program start-up: barring internal memory corruption,
>it can only be changed by the "pop3 leave on|off" command.

	- ok; and i think you've below spotted what's been happening,
	at least as regards "pop3 leave on|off", here.

>just before you do your POP3 collection, run "pop3 leave": this will
>display the current state of the setting, e.g.
>  Leave downloaded mail on server: off
>
>If it's off, that's OK; if not, something is turning it on!  You could
>narrow it down by putting "pop3 leave" at the start and end of your
>AUTOEXEC.NET file etc.

	- have done so, and will observe (& report).
[]
>BTW, if you're doing your POP3 collections by hand instead of putting
>them in AUTOEXEC.NET, I heartily recommend putting them in a file (or
>files) that you can later "source" -- that way, you only have to type
>the commands in once.  I have an assortment of such 'script' files that
>get sourced at regular intervals by the "at" command, and which can also
>be run manually e.g. "source pop3dmn.scr".

	- thanks; i've been reading up the "at" command in disview;
	i'll be trying this out (for the first time ever) tomorrow,
	after another read-through to sort out the different uses
	of the new ~\scr and ~\spool\scr directories.

>>>The fact that you're getting a "TOP M 0 failed" error means (a) that the
>>>POP3 collection system isn't in a "receiving data" state -- any data
>>>from the previous message has (apparently) finished coming in -- and (b)
>>>that it was a TOP command (which only returns the header, not the body)
>>>that failed, rather than RETR which is used to grab the whole message.
[]
>>	up to 6MB of the email in question was collected, the last time
>>	i tried seeing what happened if i just stayed online, in the wee
>>	small hours - and had to delete a lock file on the mailbox it was
>>	headed for, [], after i eventually gave up and disconnected.
>
>That's very odd.  Did you get any POP3 error messages that time, or did
>everything behave normally apart from the download not finishing before
>you gave up?

	- two pop3 messages, but only upon typing "exit<enter>"
>
>>>You can find out whether the POP3-SMTP socket is still receiving data
>>>by looking up its socket number ("socket"), then running "socket NNN"
>>>a couple of times and comparing the rcvd totals.

	- *nods*
[]
>>>The GremNOS POP3 collection picks them up in message order (1, 2, ...),
>>>which seems to be the order in which the messages arrived in the mailbox;
>>>size of message doesn't come into it.  (Although it could: see below.)
[]
>>>Two improvements spring to mind: (a) modify the POP3 collection to allow
>>>GremNOS to collect the messages in ascending size order rather than in
>>>message number order; (b) implement Pete's ESMTP SIZE restrictions for
>>>POP3 as well, which would allow you to set a size threshold above which
>>>messages wouldn't be downloaded.
>> 
>>	- will the latter reject messages above the threshold, or leave
>>	them uncollected?
>
>It could (and, I think, should) do either: I can see it being useful for
>quick downloads with a low threshold, just to see if that expected (but
>short) mail has come in yet, and leave the main download (with a higher
>threshold) for later; and the *really* big ones could be left on the
>server to be collected at the weekend.

	- *nods*  having the choice would be more flexible;

>>	if the latter, this might trigger the strange behaviour seen
>>	above, where messages rejected as killfiled/to an unknown user-
>>	name are actually left on, despite "pop3 leave off" being the
>>	most recent instruction.      - [b]
>
>AHA!  The light has just gone on.  Why didn't I think of this before?

	- because the speed of your connection means the circumstances
	are unlikely to arise?  (and possibly in part because, during
	the daytime, the m$ exchange system and/or the 08440416662 line
	was only delivering the 6+MB email in bursts, and the pop3 coll-
	ection process was eventually timing out, if i left it going ?)
>
>A possible (indeed, likely) reason why you kept getting the same
>messages left on the server every time you had a problem is that the
>POP3 connection was still active (downloading the huge message) when you
>disconnected: the server will[*] only process pending deletions when the
>client disconnects normally (by sending the QUIT command).  If the QUIT
>doesn't appear, the server will eventually time out the connection, and
>pending deletions will[*] not be performed -- so the same messages will
>be present next time you try.

	- well, i'm convinced :-)  (and it matches some symptoms.)
>
>[*] Or at least should: this is an MS server, so all bets are off wrt
>RFC compliance...
>
>One thing I always used to do on dialup just before exiting GremNOS was
>a quick "socket", to make sure there weren't any active sockets that
>would be broken off mid-stream by the impending disconnection.

	- *nods*  - though in these pop3 sniggles, the collection
	processes've been the only things uncompleted before dis-
	connection.

>Note that noe of this explains the "TOP M 0 failed" errors you saw,
>though: those can only have happened due to a real error somewhere (and
>they sound very much like loss of synchronisation between server and
>client, where GremNOS thinks the server has finished sending but it
>actually hasn't, so the next "response" is actually part of the previous
>data stream and makes no sense).
>
>I'm going to improve the error messages, which should help work out
>what's happening if the problems ever recur; I've checked the code
>carefully and can't see how TOP (or a preceding command) could be
>failing, so unless it happens again there's not a lot we can do.  (I've
>been using POP3 daily for over five years without any problems, except
>when Demon ineptly forged the postmaster e-mails and got the *ENV stuff
>wrong, and even then I still got the message).

	- which is more than i ever did; it disappeared from the long
	finger response eventually, a little before i was "migrated" -
	presumably deleted by demon/thus/clueless+witless, as mail on
	the sdps system did not sfaiaa ever expire.
>
>>>If you wish to record the session to a file, press F10 to get back to
>>>the prompt, enter "record pop3.rec" (to record to file POP3.REC) then
>>>press Enter to return to the session.  Recording will stop when the
>>>session closes, or when you enter "record off" at the net> prompt.
>>	- *nods* - except i'll need to remove any & all finger (etc.)
>>	lines from my autoexec.net when i wish to record pop3 sessions,
>
>No, you shouldn't need to do anything special, since this is a telnet
>session you'd be recording, with its own screen; the bit you were having
>trouble with previously was trying to record the main command screen,
>which is indeed impossible if you've already used F10 to escape back to
>it from another session.  (All will become clear below, if you can wade
>through that far!)

	- ok; i was referring to normal pop3 collection - so far as
	there is such a thing as "normal" with this m$ystem - but i
	evidently failed to make this clear: sorry.

	- wade in [the] water ? - it's a _long_ time since i did that
	(and it was ramsey lewis' track, anyway).  but here we go,
	slithering and sliding on, living the timeless life... (- [a])
>
>>	as something doesn't re-set when an smtp session ends
>
>SMTP sending/receiving connections actually don't have their own
>sessions -- their status messages get written to the main command
>screen.  If you telnet into a server to talk some protocol to it (port
>25 for SMTP, 110 for POP3, 119 for NNTP etc.), it's a telnet session.
>
>>	- nor, when an ftp session ends (which it used to, sort of -
>>	formerly, it'd re-set to another (the next-highest numbered,
>>	iirc) session.
>
>Are you sure KA9Q ever did this (resetting the "active session" marker
>to the next-highest-numbered session when the currently active session
>ended)?  The GremNOS code certainly doesn't behave that way, although
>it's possible to persuade yourself that it does (I managed to persuade
>myself thus earlier, before I'd understood how it really works).

	- no, gremnosceri haven't - leastways, not so far as i can
	recall since your first pplt (& the lite & large from which
	it was derived); but yes, i'm sure - 216d and other versions
	i've used since getting my very first ever (tinypcclone) 386
	i-m-t with its massive 42MB hard drive - it was a noticeable
	difference to which i took a little time to adjust, so "i'm
	certain (but i suppose i could, just about, be wrong)".

[snip most details of the way it works in plain GremNOS: there is a concept
 of the "most recently escaped from" session, which is the one with a '*'
 against its number in the session list: this is the one you return to if
 you just press Enter, and is the one recorded by a "record" command.
 The last-session marker is only set when you use F10 to escape back from
 a session to the main command screen; if you then return to that session
 and end it, thereby returning to the main command screen without pressing
 F10, the marker -- which was set to that now-defunct session -- is reset
 to nothing.]

>There's certainly an argument to be made that, when the session currently
>marked as the "last" one ends, the last-session marker shouldn't be reset
>to nothing, but should be reset to one of the other active sessions (or,
>failing that, the main command screen -- which is also technically a
>"session"); that would IMHO be better than the current system, and would
>allow you to record the main command session if you wanted to (currently
>you can do it right at the start, because the last-session marker is
>initially set to the command session, but it cannot be got back there if
>you've ever used F10).

	- i think the last-session marker resetting to the main command
	screen session, and/or the main command screen session being one
	of the options selectable with the "s(ession)" command - "s0" ?
	"main command screen" or "net> prompt" ?, and capable of having
	the last session marker associated with it, would be the most
	flexible & useful.
	(but, not knowing how much work it might involve, i can't say it
	is a particularly high priority - after all, it hasn't proved to
	be an essential fix in over two and a half decades :-) )

[snip clear definitions of & differentiation between "socket" & "session"]

	- thanks;

>I told you it was going to be long!

	- *g* you did indeed; read, marked and, for the most part,
	inwardly digested. i think. but will bear a further reread.

	- love, ppint.

	[a] - "a very cellular song" - the incredible string band

	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
a superfluous upward key-change is the last resort of the incompetent composer
  or producer of pop songs: the penultimate being the infliction of violins.

	- very brief first report:

	- the pop3 leave status is still "off"; and, since the blocking
	email was rejected, pop3 collect's been working "as advertised".

	- so that's one fewer possible pop3 problems with using the new
	mail system d/t/c+w have so thoughtfully provided to entertain us.

	- love, ppint.
	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
             "never trust a man with shaved buttocks"
             - jim darby, 2/9/96 (9/2/96 for merkins)

On Saturday, in article
     <20120922.0225.12090215snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120920.1355.933016snz@twoplaces.co.uk>,
>          simon@twoplaces.co.uk "Simon Turner" pondered & pronounced:
> >[This is going to be rather long: apologies in advance.]
> [still fairly long...]
> >                         "ppint. at pplay" wrote:
> >>        simon@twoplaces.co.uk "Simon Turner" commented & explained:
> >>>                       "ppint. at pplay" wrote:
> >>>>    (following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
> >>>>                         in which i wrote):
> 

[big snip]

> >>>[...] (b) implement Pete's ESMTP SIZE restrictions for
> >>>POP3 as well, which would allow you to set a size threshold above which
> >>>messages wouldn't be downloaded.
> >> 
> >>      - will the latter reject messages above the threshold, or leave
> >>      them uncollected?
> >
> >It could (and, I think, should) do either: I can see it being useful for
> >quick downloads with a low threshold, just to see if that expected (but
> >short) mail has come in yet, and leave the main download (with a higher
> >threshold) for later; and the *really* big ones could be left on the
> >server to be collected at the weekend.
> 
>         - *nods*  having the choice would be more flexible;

After a suggestion from Pete, I think it needs three settings for what
to do with large messages: 0 = leave on server; 1 = delete and send DSN
to sender to explain; 2 = delete without informing sender.  Default = 0.

> >[...]  (All will become clear below, if you can wade
> >through that far!)
> 
>         [...]
> 
>         - wade in [the] water ? - it's a _long_ time since i did that
>         (and it was ramsey lewis' track, anyway).  but here we go,
>         slithering and sliding on, living the timeless life... (- [a])

8-)

> >>      - nor, when an ftp session ends (which it used to, sort of -
> >>      formerly, it'd re-set to another (the next-highest numbered,
> >>      iirc) session.
> >
> >Are you sure KA9Q ever did this (resetting the "active session" marker
> >to the next-highest-numbered session when the currently active session
> >ended)?  The GremNOS code certainly doesn't behave that way, although
> >it's possible to persuade yourself that it does (I managed to persuade
> >myself thus earlier, before I'd understood how it really works).
> 
>         - no, gremnosceri haven't - leastways, not so far as i can
>         recall since your first pplt (& the lite & large from which
>         it was derived); but yes, i'm sure - 216d and other versions
>         i've used since getting my very first ever (tinypcclone) 386
>         i-m-t with its massive 42MB hard drive - it was a noticeable
>         difference to which i took a little time to adjust, so "i'm
>         certain (but i suppose i could, just about, be wrong)".

Very odd; I've checked the source for 2.16d and it works exactly the
same way as GremNOS, i.e. the "current session" info passed to commands
like "record" is the "most recently escaped from" session, which is
initially set to the main command session.  If the "most most recently
escaped from" session ends, the marker is reset to nothing, and remains
that way until next time you use F10.

However, as discussed, there's no reason why it should remain that way!

>         - i think the last-session marker resetting to the main command
>         screen session, and/or the main command screen session being one
>         of the options selectable with the "s(ession)" command - "s0" ?
>         "main command screen" or "net> prompt" ?, and capable of having
>         the last session marker associated with it, would be the most
>         flexible & useful.

I definitely think that resetting the last-session marker to the command
screen, rather than nothing, when the current last-session ends would be
a Good Thing.  I'm still thinking about whether making "s 0" return you
to the main command screen would be useful (if you can type "s 0",
you're already there!); perhaps it might be useful in scripts in a way I
haven't thought of yet.

>         (but, not knowing how much work it might involve, i can't say it
>         is a particularly high priority - after all, it hasn't proved to
>         be an essential fix in over two and a half decades :-) )

True, until I wanted you to record the POP3 trace stuff and you
couldn't...

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

On Monday, in article
     <20120924.0053.12090222snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - the pop3 leave status is still "off"; and, since the blocking
>         email was rejected, pop3 collect's been working "as advertised".

Good; thanks for the report!

>         - so that's one fewer possible pop3 problems with using the new
>         mail system d/t/c+w have so thoughtfully provided to entertain us.

It *was* kind of them, wasn't it?

It's interesting (and rather sad) how many old hands are departing after
being migrated to the unfit-for-purpose new mail system.  Sigh.

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

	- hi; in article, <20120925.1108.933182snz@twoplaces.co.uk>
	  simon@twoplaces.co.uk "Simon Turner" reported & commented:
>	                ppint. at pplay" wrote:
>>	  simon@twoplaces.co.uk "Simon Turner" pondered & pronounced:
>> >[This is going to be rather long: apologies in advance.]
>> [still fairly long...]
>> >	                "ppint. at pplay" wrote:
>> >>	   simon@twoplaces.co.uk "Simon Turner" commented & explained:
>> >>>	                "ppint. at pplay" wrote:
>> >>>>	(following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
>> >>>>	                  in which i wrote):
>> 
>[big snip]
>> >>>[...] (b) implement Pete's ESMTP SIZE restrictions for
>> >>>POP3 as well, which would allow you to set a size threshold above which
>> >>>messages wouldn't be downloaded.
[]
>After a suggestion from Pete, I think it needs three settings for what
>to do with large messages: 0 = leave on server; 1 = delete and send DSN
>to sender to explain; 2 = delete without informing sender.  Default = 0.

	- sounds good;
[]
>> >>    - nor, when an ftp session ends (which it used to, sort of -
>> >>    formerly, it'd re-set to another (the next-highest numbered,
>> >>    iirc) session.
>> >Are you sure KA9Q ever did this (resetting the "active session" marker
>> >to the next-highest-numbered session when the currently active session
>> >ended)?  The GremNOS code certainly doesn't behave that way, although
>> >it's possible to persuade yourself that it does (I managed to persuade
>> >myself thus earlier, before I'd understood how it really works).
>>	- no, gremnosceri haven't - leastways, not so far as i can
>>	recall since your first pplt (& the lite & large from which
>>	it was derived); but yes, i'm sure - 216d and other versions
>>	i've used since getting my very first ever (tinypcclone) 386
>>	i-m-t with its massive 42MB hard drive - it was a noticeable
>>	difference to which i took a little time to adjust, so "i'm
>>	certain (but i suppose i could, just about, be wrong)".
>
>Very odd; I've checked the source for 2.16d and it works exactly the
>same way as GremNOS, i.e. the "current session" info passed to commands
>like "record" is the "most recently escaped from" session, which is
>initially set to the main command session.  If the "most most recently
>escaped from" session ends, the marker is reset to nothing, and remains
>that way until next time you use F10.

	- so what on - or off - earth have i - or my computer(s) - been
	doing ?

	- the first two or three sessions were f status@gate, f report@
	gate & f i-m-t+@post, added at the end of autoexec.net, the fourth
	being ftp homepages, by keyboard; on quit<enter>-ing the completed
	ftp session, and <enter>-ing once more (as directed on-screen), to
	return to the net>, i used not to have to select an open session
	by s <1-3>: just <enter> gave the third (long finger) session.

	- hmmm. it might've been something removed/lost when richard gave
	us the y2k- & other-fixes version of the KA9Q/dis 'net suite (or
	was it initially only the fixed KA9Q/net.exe ?  - i think it was
	the full suite...); i moved over (? or back to*) a y2k-fixed grem-
	nos that i think i read incorporated his fixes and updates pretty
	soon after, so i mightn't've noticed the change, if it happened
	then.

	(* i _think_ i was still using the un-y2k-fixed KA9Q/net.exe from
	the demon 'net suite until then, but i'm no longer on that pc and
	its hard drive is one of the several somewhere downstairs.)

	(i'm _fairly_ sure i'm not/was not hallucinating the behaviour...)

>However, as discussed, there's no reason why it should remain that way!

	- sounds promising, very promising;-)

>>	- i think the last-session marker resetting to the main command
>>	screen session, and/or the main command screen session being one
>>	of the options selectable with the "s(ession)" command - "s0" ?
>>	"main command screen" or "net> prompt" ?, and capable of having
>>	the last session marker associated with it, would be the most
>>	flexible & useful.
>
>I definitely think that resetting the last-session marker to the command
>screen, rather than nothing, when the current last-session ends would be
>a Good Thing.  I'm still thinking about whether making "s 0" return you
>to the main command screen would be useful (if you can type "s 0",
>you're already there!); perhaps it might be useful in scripts in a way I
>haven't thought of yet.

	- *g*  - i was only thinking that, if it required a session no.
	in order to be selectable via the last session left marker, and
	that were the simplest and most concise method of achieving the
	desired objective, session no. 0 would appear always to be avail-
	able and possess the minor advantage of never needing to respond
	to the "s<enter>" poll of current active sessions - unless it be
	considered desirable that one could find out what had been left
	(invisibly) running, but had been completely forgotten about ?

>>	(but, not knowing how much work it might involve, i can't say it
>>	is a particularly high priority - after all, it hasn't proved to
>>	be an essential fix in over two and a half decades :-) )
>
>True, until I wanted you to record the POP3 trace stuff and you couldn't...

	- *g*  - though this _was_ workable-around...

	- love, a ppint. off to replace my pop3 password with one i don't
	mind sharing - yup, it's happened again, and you did say you'd like
	the chance to find out what was causing the 'TOP N 0' failed: ''
	(after pop3 sent: top 30, and pop3 receive failed: ???) to appear.

	- and, wonder of wonders, it's not raining! 

	- and there's this weird, yellowy light reflecting off the leaves
	and things!

	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
 "What are your fees?" inquired Guyal cautiously. "I respond to three
 questions," stated the augur. "For twenty terces I phrase the answer
 in clear and actionable language; for ten I use the language of cant,
 which occasionally admits of ambiguity; for five, I speak a parable
 which you must interpret as you will; and for one terce, I babble in
 an unknown tongue."  "Guyal of Sfere", _The Dying Earth_- Jack Vance

On Wednesday, in article
     <20120926.0904.12090231snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk ""ppint. at pplay"" wrote:

> 	- hi; in article, <20120925.1108.933182snz@twoplaces.co.uk>
> 	  simon@twoplaces.co.uk "Simon Turner" reported & commented:

[...]
> >Very odd; I've checked the source for 2.16d and it works exactly the
> >same way as GremNOS, i.e. the "current session" info passed to commands
> >like "record" is the "most recently escaped from" session, which is
> >initially set to the main command session.  If the "most most recently
> >escaped from" session ends, the marker is reset to nothing, and remains
> >that way until next time you use F10.
> 
> 	- so what on - or off - earth have i - or my computer(s) - been
> 	doing ?

I couldn't possibly comment. 8-)

> 	- the first two or three sessions were f status@gate, f report@
> 	gate & f i-m-t+@post, added at the end of autoexec.net, the fourth
> 	being ftp homepages, by keyboard; on quit<enter>-ing the completed
> 	ftp session, and <enter>-ing once more (as directed on-screen), to
> 	return to the net>, i used not to have to select an open session
> 	by s <1-3>: just <enter> gave the third (long finger) session.

Hmmm.  How did this appear from your POV?  I just tried it with GremNOS,
with the three finger commands at the end of AUTOEXEC.NET, and it opened
all three finger sessions, leaving me in the final one (the long finger,
in this case), so I had to use F10 to get back to the prompt: the F10
set the last-session marker to that third session, so once the manual
ftp session ended and I pressed <enter>, I was returned to the long
finger session.  So far, so good.  But when I ended that session by
pressing <enter> to get back to the prompt, the last-session marker was
no longer set, so pressing <enter> on its own again didn't achieve
anything.

If I put something else in AUTOEXEC.NET after the finger commands, I
started off at the command screen, but the last-session marker started
off unset and remained so after the end of the manual ftp session, so
pressing <enter> never did anything.

How did it work (in terms of what session screen you saw when) under the
old system?

> 	- hmmm. it might've been something removed/lost when richard gave
> 	us the y2k- & other-fixes version of the KA9Q/dis 'net suite (or
> 	was it initially only the fixed KA9Q/net.exe ?  - i think it was
> 	the full suite...); i moved over (? or back to*) a y2k-fixed grem-
> 	nos that i think i read incorporated his fixes and updates pretty
> 	soon after, so i mightn't've noticed the change, if it happened
> 	then.

I don't think so; Richard didn't change any of this stuff when he did
his 2.18 Y2K-compatible version.  I've checked the source code back to
2.12 from July 1993, and all of them (2.12, 2.16d, 2.18 and GremNOS)
handle moving between sessions the same way: indeed the source code
files in question (SESSION.C and MAIN.C) didn't change significantly
between 2.12 and 2.18 (and the only changes in GremNOS relate to the
TextWin versions).

I must confess I'm baffled by this, because the source code doesn't seem
to have changed at all, and yet you're seeing different behaviour...

[...]
> >I definitely think that resetting the last-session marker to the command
> >screen, rather than nothing, when the current last-session ends would be
> >a Good Thing.  I'm still thinking about whether making "s 0" return you
> >to the main command screen would be useful (if you can type "s 0",
> >you're already there!); perhaps it might be useful in scripts in a way I
> >haven't thought of yet.
> 
> 	- *g*  - i was only thinking that, if it required a session no.
> 	in order to be selectable via the last session left marker,

It doesn't: the last-session marker is actually a so-called pointer (a
variable containing a memory location) that "points to" (i.e. contains
the location of) the area of memory containing the details of the
session in question, which can as easily be the command session as any
other; when unset, it "points to" memory location 0, a special value
known as NULL, making the variable a "null pointer".  (I bet you didn't
expect to have a C programming lesson! 8-)

In reality, the main command session is genuinely session 0; it is
intentionally not displayed in the "session" list.

>       and
> 	that were the simplest and most concise method of achieving the
> 	desired objective, session no. 0 would appear always to be avail-
> 	able and possess the minor advantage of never needing to respond
> 	to the "s<enter>" poll of current active sessions - unless it be
> 	considered desirable that one could find out what had been left
> 	(invisibly) running, but had been completely forgotten about ?

The main command session is the underlying foundation of the whole
program, and is *always* running; as soon as it finishes, NET.EXE stops
running.  Having it show up in the "session" ("s") list wouldn't tell
you anything useful IMHO; but having other invisible-but-running
sessions show up in the list is indeed valuable.

A thought: one could make the last-session-marker behaviour work the way
you described above, so that when the current last-session ends, it gets
reset to the most-highly-numbered session currently running (which would
be the command session if there are no others); this would mean that
"record" will *always* work, and pressing <enter> will always take you
to a running session if there are any left.

If you wanted to set the last-session marker to the main command session
while leaving other sessions running, in order to record the command
session, "session 0" could be a special case that does just that.

The last-session marker would thus always be set to something: if it
shows up in the "session" list, it's the indicated session; if not, it's
the main command session.

I think that might actually be the best all-round solution; what does
anyone else think?

> 	- love, a ppint. off to replace my pop3 password with one i don't
> 	mind sharing - yup, it's happened again, and you did say you'd like
> 	the chance to find out what was causing the 'TOP N 0' failed: ''
> 	(after pop3 sent: top 30, and pop3 receive failed: ???) to appear.

I would indeed like to find out what causes the TOP commands to fail;
I've responded to this in e-mail (sent to punt-1 rather than mx1 to give
you a chance of receiving it).

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

On Wednesday, in article
     <20120926.1242.933235snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Wednesday, in article
>      <20120926.0904.12090231snz@i-m-t.demon.co.uk>
>      v$af$ppint@i-m-t.demon.co.uk ""ppint. at pplay"" wrote:

[...]
> > 	- love, a ppint. off to replace my pop3 password with one i don't
> > 	mind sharing - yup, it's happened again, and you did say you'd like
> > 	the chance to find out what was causing the 'TOP N 0' failed: ''
> > 	(after pop3 sent: top 30, and pop3 receive failed: ???) to appear.
> 
> I would indeed like to find out what causes the TOP commands to fail;
> I've responded to this in e-mail (sent to punt-1 rather than mx1 to give
> you a chance of receiving it).

I've replied, again to punt-1, so with any luck you'll receive the two
messages I sent (it's a long story); the executive summary is that sadly
I couldn't determine anything about what caused the TOP failure, because
the message that caused it (which will have been the previous one that
was processed) was presumably DELEted when your POP3 collection
operation ended.  Sigh.  Improved error messages should help next time
it happens!

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer