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).
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.