Excerpts from mail.cypherpunks: 2-Feb-96 Re: FV Demonstrates Fatal F.. "Paul M. Cardon"@fnbc.co (1751*)
I can guarantee you that it wasn't our system that did this. If there's one things we know cold, it's email.
C'mon Nathan. It was in the Received headers generated at your end. I agree that it COULD have happened on our end, but it didn't. I've never seen anybody with such an arrogant attitude. BTW, it looks like it has been fixed now. :-b
Well, I would think that if you were seriously trying to diagnose this problem, you would have heeded my request and actually sent me the Received headers that you claim prove that there was a problem on my end. I've been tracking down mail delivery problems for fifteen years now, I take them *excruciatingly* seriously, and I think I know a *little* bit about them. If that makes me arrogant, I apologize. Received headers are typically (but not always) added at each step along the way as a mail message travels in a store-and-forward manner. Mail that leaves my system typically(i.e. using my preferred user agent) has two Received headers by the time it leaves, and neither of them specify the destination address at all. Received headers don't generally include destination informations, but may include them optionally, using a FOR clause. Any Received header that actually included the bogus address you specified is definitely not generated by my machine, not merely because I'm confident it wouldn't use that address, but more critically because that clause of Received headers (FOR) isn't EVER generated by my machine! That's how I can be so absolutely sure that it wasn't added by my machine. When messages leave my machine they have two Received headers, using these formats: Received: by nsb.fv.com (4.1/SMI-4.1) id AA26452; Fri, 2 Feb 96 16:40:24 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.nsb.fv.com.sun4.41 via MS.5.6.nsb.fv.com.sun4_41; Fri, 2 Feb 1996 16:40:23 -0500 (EST) Note the complete absence of any FOR clause here. It doesn't matter WHO my system is sending mail to, it doesn't document the fact in the Received headers. (NOTE TO C'PUNKS: In general, any mail relay that uses the FOR clause for anything other than "final" delivery -- a very tricky concept, by the way -- is indulging in a potentially very serious breach of privacy, which should certainly concern the readers of this list. That's because it is typically based on the envelope addresses rather than the header addresses, and hence can expose recipient names that the sender thinks were being kept confidential, such as BCC addresses. That's one reason I prefer not to use the FOR clause at all.) Note also that Received headers almost always appear in reverse order of composition, because most relaying software just prepends them. This means that the mail you got from me probably has two headers like this one, and that the one before it is the first one added by any machine other than mine. Most likely, the one before this is added at FV's mail relay. I don't *think* it uses "FOR" clauses either, but I can't swear to that. I hope this is helpful. This is as far as I can go in diagnosing this problem without actually seeing the mail headers you claim to have received. If you have any interest in diagnosing the real problem, as opposed to publicly flaming me, I encourage you to send me the headers. I also see no point whatsoever in continuing to CC cypherpunks on the diagnosis of a mail delivery problem, but will continue to do so in my replies if you continue to send mail to cypherpunks slandering my technical abilities in the guise of talking about a mail delivery problem for which you refuse to provide documentary evidence that is allegedly in your posession. -- Nathaniel -------- Nathaniel Borenstein <nsb@fv.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: nsb+faq@nsb.fv.com