Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit

[Nathaniel Borenstein <nsb@nsb.fv.com>]

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