Date: 26 Nov 2000 From: Heimo Claasen <[EMAIL PROTECTED]> Subject: using 'delete old' has become a problem The quite practical - and as "safe" considered - functionality with Nettamer 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 this list, send a message to [EMAIL PROTECTED] with the single word Unsubscribe as the subject. You MUST use the same address with which you subscribed! ********************************************************
