From owner-freebsd-hackers Mon Feb 17 16:06:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA26313 for hackers-outgoing; Mon, 17 Feb 1997 16:06:07 -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 QAA26306 for ; Mon, 17 Feb 1997 16:06:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09940; Mon, 17 Feb 1997 17:03:55 -0700 From: Terry Lambert Message-Id: <199702180003.RAA09940@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 17:03:55 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, fetchmail-friends@snark.thyrsus.com In-Reply-To: <199702172344.PAA28691@precipice.shockwave.com> from "Paul Traina" at Feb 17, 97 03:44:23 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'm kind of hesitant to consider "Return-Path:" in the UID generation; > I would much, much prefer that a timestamp of the form: > > YYYYMMDDHHMMSSII > > No, you don't understand. QPOP computes the UIDL by calculating a MD5 hash > across the entire message header (not including fields that can change, such > as Status:). The server previously did not include the envelope from > information in the hash (the From_ line). I am now including the Return-Path: > line in the hash. I am just adding more data to the hash. I still don't think a hash is the right way to go... 8-(. > Additionally, if a message is already in the spool file with an X-UIDL line > in it, QPOP will use that computed value instead of recomputing its own, > which is why I can get away with adding Return-Path: to the hash. X-UID? ...UIDL: (Unique ID List) is a Pop3 command; the quantity being described is a UID, not a UIDL. > I'd like the UIDL to simply be the message ID, but frankly, they are NOT > unique, and the author of QPOP realized that too. ??? OK... why are the message Id's unique? Timestamp not included, maybe? > I have to say that this kind of empirical testing isn't very useful. > > Actually, it is. It makes sure that the old UIDs are persistant across > POP sessions, and that the new hash change didn't screw anything up, assuming > that your MUA uses UID's as specified by POP3. :-) Well, for data which already exists. It won't cause a full branch-path code verification, which is really the type of test you want. All you will find out is that it doesn't screw your testers, not that it won't screw them or you in the future. That's a bad thing... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.