Hi there Stuart,
Thanks for your explanation. *8)
The big problem, as I see it, is that we can't pass the From: header,
sent in the DATA part of the message, through SPF since we can't
guarantee to extract the original IP sender on all messages, at least
for today. This generates a big issue since most of the mail clients use
the From: header sent in the DATA header so we still have the problem.
But what if, only when the Sender-Envelope email address is different
from the From: header email address, we change the From: header to the
Sender-Envelope, forcing the mail clients to see who really sent the
message, and put the "user inserted" From: Header on other X-whatever
header so at least the common user, that doesn't understand nothing
about SPF and so on, sees that a message that is sent from their Bank
for example, didn't come directly from them, but from another sender?
Wouldn't that be more reasonable? I mean, if I get an email sent on my
behalf by someone that isn't me I wan't the person receiving it at least
seeing who sent it no just putting my email up there at the From on my MUA.
What do you think on that?
Best regards and thanks again,
------------------------------------------------
Rodrigo Afonso
rafonso(_at_)rits(_dot_)org(_dot_)br
Gerente TI
RITS - Rede de Informações para o Terceiro Setor
------------------------------------------------
http://www.rits.org.br
Rua Guilhermina Guinle, 272/6º Andar
Rio de Janeiro/RJ - CEP: 22270-060
Tel: (21) 2527-5494 / Fax: (21) 2527-5460
Stuart D. Gathman wrote:
On Tue, 27 Jul 2004, Rodrigo F Afonso wrote:
I can see that mostly the emails that come with different From and the
Return-Path are from Lists (like Yahoo Groups) and Spammers trying to
pass out Scam's.
My question is, how are you people treating this case on your MTA's? As
I can see it the only solution is, IMHO, on cases where the From is
differente from the Return-Path to change the From Header at the MTA to
another name so the MUA's are forced to use the Return-Path as the
sender. But that is against a lot of RFC's.
Yahoo Domain Keys addresses authenticating internal headers by
cryptographically signing the From header with the message contents.
The weakness of DK is that if an MTA modifies the message body (e.g.
a mailing list appending list info or M$ Exchange converting character
sets), the signature is broken.
M$ CID is also supposed to do some kind of check on internal headers.
SPF and DK are easy to understand, but for CID/senderID I am not sure I
understand how it helps that much. My understanding is that CID requires
the envelope sender to match an internal header - either Sender
or From. There also seems to be a provision for forwarders to
pass along the original Sender via a SUBMITTER ESMTP extension, or
via (currently deprecated but still valid) source routing.
The submitter business is trivial to forge, so you still end up
having to whitelist trusted forwarders (although SPF lets you do so
by domain instead of IP) before you can believe what they say about
the SUBMITTER.
So the basic idea of CID is that if
1) the envelope sender gets SPF pass and matches Sender or From
or
2) the envelope sender gets SPF pass and is trusted and SUBMITTER
matches Sender or From
then the matching Sender/From header has been "verified", and presumably this
information will eventually be passed on to the user via upgraded
MUAs.
The plan is that in the future, when SPF and senderID are widely
implemented, then MTAs can start rejecting mail without an internal
Sender/From that verifies.
Also note that if a forwarder uses SRS in the standard format, then the
receiving MTA can extract the original SUBMITTER from the SRS encoding even
if not provided via source routing or ESMTP.
A weakness with senderID is that it seems to break SES (doing SRS
or something like it at the original sender to be able to block
forged bounces and allow CBV).