ietf-mxcomp
[Top] [All Lists]

RE: Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-26 11:57:44

 
On Friday, April 23, 2004 12:29 AM, Greg Connor
[mailto:gconnor(_at_)nekodojo(_dot_)org] wrote:

[snip]
It's a bit disingenuous to suggest that 2821 MAIL FROM has 
problems with forwarding, while 2822 From:/Sender: do not.  
Of course they have different solutions, SRS/VERP vs. adding 
acceptable headers.  You say potayto, I say potahto.

I am acutely aware that even with 2822 header checking there are only a
limited number of cases when you can confidently reject mail with low
risk of false postives.  But then I am not the one suggesting there is a
rich prize of bandwidth savings to be had by rejecting messages at MAIL
FROM.   


Also, there are other ways to handle forwards besides 
SRS/VERP.  Check out the SPF FAQ, it should be there... I 
seem to recall there are at least two others.  In particular, 
you may not want the returns to go back to the original 
author (such as this list).


Come up with a scheme or set of conditions that enables 
receivers to 
correctly reject messages based solely on RFC2821 MAIL FROM.  This 
scheme must work in the face of forwarders who have not implemented 
SRS, VERP or any similar mechanisms since they are likely 
to represent 
the majority of forwarders for the foreseeable future and 
will remain 
present on the Internet indefinitely.  And just so we don't 
go into an 
infinite loop on this, let's set a deadline, say midnight Pacific 
time, Friday, April 30, for finding such a scheme.


In that case, here is an easy one:  altavista.com.  It sends 
NO mail, so therefore it is safe to block ALL mail claiming 
that MAIL FROM without examining any headers.

Margaret Olson has dealt with this in an earlier posting. 

Here is another one:  Anyone who is interested in MS-CID's 
directOnly feature would probably also want receivers to drop 
mail not coming from a specified IP.  Does directOnly have a 
valid reason for existing?  Could you not then concede that 
some domains will want strict 2821 checking also?

The main purpose of DirectOnly is to indicate the domain does not to
send to mailing lists. 
So if a receiver receives a message from such a tagged domain which
looks like it came through a mailing list, it can be unilaterally
rejected.  Of course this cannot be determined from the 2821 MAIL FROM
alone.  

In the forwarding case, in order to reject mail, the receiving side
needs to be certain that all of their users have whitelisted their
forwarded addresses.  To reject mail at MAIL FROM imposes the additional
requirement that receivers know the mail has not come through a non-SRS
forwarder.  That seems to imply essentially universal adoption of SRS by
forwarders.  Given the radical heterogeneity of the Internet, universal
adoption is just not on the menu.
 
[snip]
For me, bandwidth savings is actually not the #1 or even #2 
reason for insisting on MAIL FROM validation.  My #1 reason 
is that I don't want to receive bounces from crap I didn't send.

Eliminating invalid bounces is a great goal.  Unfortunately it cannot be
achieved by the methods you're proposing.  

You cannot use SRS or any form of MAIL FROM rewriting to prevent joe
jobs.  It won't work.  The reason is that the receiver of the spoofed
mail has no way to distinguish mail from an SRS-compliant MTA from mail
that has been routed through a non-SRS compliant forwarder.  The only
way the receiver can reliably reject messages is that there remain no
significant population of non-821-checkers out there on the internet
that the spammers can find.  That is, if effectively everyone did the
check, then it might work, but thinking we'd ever even remotely get
there is, with all due respect, fantasy.  

BTW, it's not clear that SRS is something that falls under the MARID
charter anyway.  If organizations wish to implement it, that's their
choice of course.  MARID, however, needs to draft something that will
work in the face of non-SRS forwarders as well. 

The only feasible way to stop joe jobs is for the receiver of the NDR
(not the receiver of the original message) to insert information in his
legitimate messages so he can determine whether a received NDR pertains
to a message that was actually sent out from that domain or not.  This
kind of solution can be implemented unilateraly by each receiving MTA
and does not require universal deployment of rewriting schemes in order
to be efffective.  This is also outside the charter of the MARID group.