🚀 go-pugleaf

	- 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.