At 01:34 PM Thursday 3/25/99, Scott Schwartz wrote:
>Dirk Alboth <[EMAIL PROTECTED]> writes:
>| As I understand RFC 822 this is not violating the standard but in this
>| case a "Sender:" field should reveal the true sender's identity
>| (agreed?).
>
>Should != Must. You can't stop people from lying.
>
>Your only recourse is to cryptographically sign messages. Then the
>recipients have some way to check the veracity of the putative sender.
>
>I wouldn't bother hacking qmail when the cryptographic solution is
>philosophically and practically superior.
>
>| Now the "true" sender name will be ${TCPREMOTEINFO}@${TCPREMOTEHOST}
>
>Pointless, since TCPREMOTEINFO is whatever the sender wants it to be.
>It's for debugging, not security.
As an addendum to Scott's observations, TCPREMOTEHOST (or leastwise
TCPREMOTEIP) is recorded in the Received: header so you have certainty over
knowing which IP address originated the email. That's probably not useful
for a remote recipient, but assuming you have access to your
IPaddress->location information, you will be able to identify the sending PC.
Of course if a malicious insider has used some other persons PC, you wont
know from either Received: or Sender: headers. Certainly if someone accussed
me of sending an email based solely in Sender: or Received: I would get most
indignant (especially if I hadn't sent it :> )
So, as Scott says. Nothing shy of well deployed crypto-signatures help
identify the true sender.
Regards.
