The quite practical - and as "safe" considered - functionality with
Nettamer (and I think, of other mailer clients too, with DOS and other
OSs) to "delete old" mails with a next connection to the mailserver
has become problematic: I made the experience that a number of ISPs,
since about mid-year, have introduced new server-internal routines
which do not keep mails in the order given between connections, and do
not add new mails at the end of the list of kept items, but shuffle
new mail into the queue left in a haphazard manner. This can have
destructive consequences.
Earlier, when one used "download new" and "delete old" (mails) as mail
maintenance service, the downloaded ones would be kept in the number-
order they had been; lower numbers than the first "new" would be
deleted. This with those POP3 servers which have the (RFC-"optional")
command "last (message read)" implemented. Incoming new mails would be
added at the end of the list, after the "last" read item. With a next
connection to the server, the "last" one read would be the last of the
"new" items downloaded with the preceding run, "new" ones would follow
in number order (i.e., of the "list" result) and would be downloaded
as such, only the "old" (from the "last" read down to number 1 in the
"list") would be deleted (whith actual execution only after the
disconnect of the client).
This worked quite fine, as a safety net and for cases of problematic
download conditions.
Dang it but this is over - of the five POP3 mailservers I have access
to, the three which *did* have the "last" command still implemented,
have introduced other server maintenance routines which make this "last"
command - and thus the functionality to "delete old only" in a next
connection - unreliable:
New, incoming mails get stuck in at hazard at places somewhere in the
range of the "last" number of mails - these then are not downloaded as
"new" ones but deleted as "old" ones, while some really old/read ones
are pushed up in the number order and downloaded as "new". Effect is
loss of mail.
This very unser-unfriendly behaviour is, regrettably, compliant with
the POP3 (RFC-)standards which indeed oblige the server to "lock" (and
not to change anything) *only during* the connection time of a client.
The RFCs don't say anything about the time in-between client
connections; though it was evidently practice at the servers, earlier,
to not mess up the sequential order of kept mails, and to add incoming
new ones at the end of the list, sequentially.
>From other indications (e.g., incorrect use of 8-bit filtering) it has
been evident that a lot of bad "upgrading" at hitherto reliable POP3
servers has gone on, since about June last. The earlier, user-friendly
practice for keeping good sequential order is just one victim of this.
POP3 server do set the (one) bit for "read"/downloaded mails still,
internally, but POP3 CLIENTS HAVE NO MEANS TO CHECK FOR THIS, an
appropriate protocol command is simply lacking; the earlier "last"
command, which had become "optional" (and thus was dropped presto
subito by many servers) was the only check of of sorts available.
It's another screw in the spiral of increasing build-in wastefulness -
to be sure of correct downloading and housekeeping, the client has to
stay connected all the time it may take to check for errors, eventually
to repeat downloads, etc.: telco fees, bandwidth and all the rest
included.
I think this is a very bad development. And a case for revision of the
POP3 RFCs.
The author of the famous Linux "fetchmail", Eric Raymond, btw,
straightly wished those responsible for that mess to go to hell.
// Heimo Claasen // <hammer at revobild dot net> // Brussels 2000-11-26
The WebPlace of ReRead - and much to read ==> http://www.inti.be/hammer
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
