ietf-mxcomp
[Top] [All Lists]

Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-22 22:27:28
As I understand it, the proponents of basing MTA validation on RFC2821 MAIL 
FROM believe the main benefit of this approach is that it saves bandwidth.  
Specifically, a check of RFC2821 MAIL FROM is believed to allow rejection of 
messages before the content is transmitted.  
 
I've been trying to identify the conditions when this is actually possible.  
Specifically, when can you reject a message based *only* on a check of RFC2821 
MAIL FROM?    
 
Thus far I've come up with exactly zero cases where RFC2821 MAIL FROM by itself 
can be used to reject mail.
 
So I'm asking for your help.  When, if ever, can this be done?
 
Under the current schemes, as I understand them, a validation of RFC2821 MAIL 
FROM that fails *cannot* be used to reject messages because there is a high 
probability of a false positive, i.e. an erroneous rejection.  To whit:
 
- the sender could be a forwarder who has not implemented SRS or VERP.  
- the sender could be a student connected to a college campus network sending 
mail from a POP or IMAP client using their ISP's email address.  
- the sender could be a salesperson with a Blackberry sending mail over a 
carrier's network using their corporate email address. 
 
So, I would like to propose a challenge to the MAIL FROM advocates:  
 
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.
 
It would be fantastic if we could reject tons of spoofed mail at MAIL FROM.  My 
colleagues at Hotmail would be delighted, as would Exchange enterprise 
customers.  If we can identify such a scheme or set of conditions or whatever, 
then I truly believe it will be possible to craft a single validation scheme 
that leverages the best of both the RFC2821 and RFC2822 approaches and I will 
happily throw my energies into developing a converged algorithm.  
 
If we cannot identify any such scheme or set of conditions, then let's admit 
there are unfortunately no bandwidth savings to be had and let's drop RFC2821 
MAIL FROM from the list of candidate identities.