From owner-freebsd-hackers Mon Feb 17 14:58:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA22329 for hackers-outgoing; Mon, 17 Feb 1997 14:58:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA22323 for ; Mon, 17 Feb 1997 14:58:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA09811; Mon, 17 Feb 1997 15:56:22 -0700 From: Terry Lambert Message-Id: <199702172256.PAA09811@phaeton.artisoft.com> Subject: Re: looking for QualComm qpopper testers to try new patch To: pst@shockwave.com (Paul Traina) Date: Mon, 17 Feb 1997 15:56:22 -0700 (MST) Cc: hackers@freebsd.org, fetchmail-friends@snark.thyrsus.com In-Reply-To: <199702172216.OAA28519@precipice.shockwave.com> from "Paul Traina" at Feb 17, 97 02:16:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've got a patch to QualComm's QPOP 2.2 that generates Return-Path: lines > in place of the ommitted "From_" line information (which QPOP has incorrectly > ignored for years). This patch should work well with the newly updated > version of Fetchmail that now respects Return-Path: lines. The "From" line is dumped in when leaving an RFC821 transport. I believe you are (incorrectly) assuming that all your mail came from an RFC821 transport. RFC822 does NOT require a From line; in point of fact, it can cause errors on some clients, since the stamp is not necessarily the only way to seperate messages, and the From line is not a valid RFC822 header and may prematurely terminate RFC822 message parsing used to extract little things -- like, oh, say, "boundry=..." from a MIME header line indicating MIME encapsulation is occurring in the RFC822 message body. Anyway... > I'm looking for victims who UNDERSTAND THE POP PROTOCOL to test this patch. > I know it generates the Return-Path: properly, but I don't know if it is > handling the UIDL generation in a deterministic fashion (I hope it is). > > Note: UIDL's generated by this new version of QPOP include the Return-Path: > line in their calcualtion, whereas the old QPOP did not. Therefore on-the > fly UIDL generation is different in the new version, However, since QPOP > stores the first calcualted UIDL, this /shouldn't/ cause your MUA to think > old messages are now new again. > > Of course, that's what I need someone to test (since I don't use UIDLs). Download an older version of Netscape with the POP3 client (you should see RFC1939 for details). I'm kind of hesitant to consider "Return-Path:" in the UID generation; I would much, much prefer that a timestamp of the form: YYYYMMDDHHMMSSII (where II == instance for a given second) be placed in an "X-UID:" or a "Message-ID:" header by the transport (not generated on the fly by the QPopper). I don't think it's the QPopper's responsibility, I think it's the message store's responsibility, and sendmail is the (current) maintainer of your message store. A "Message-ID:" would be doubly helpful, in that it would allow threading of the (nominally SMTP-created) list archives... really necessary to make the archives even marginally useful. > If you don't know what a UIDL is, and why it's used, or you're not > sure your MUA is using UIDLs to determine which messages it has already > seen, then please don't bother testing this. Heh, sorry, my MUA doesn't use the UIDL Pop3 command to list UID's. > Things I need answered: > > (a) Did this cause you to download old messages left on server > as if they were new again? (hopefully not) > (b) If you leave mail on the server, do you get stuck downloading > that same message over and over again every time you start > your pop client. I have to say that this kind of empirical testing isn't very useful. Another mechanism, if you *must* generate "on the fly", is to generate a lexical index on user authentication to a particular maildrop, then MD5 the full message body. The timestamp from the SMTP will be different in any case (think SMTPd generation of "Apparently-To:" from the "RCPT TO:..." line). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.