ietf-mxcomp
[Top] [All Lists]

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

2004-04-24 07:22:10


----- Original Message ----- 
From: "Olson, Margaret" <molson(_at_)constantcontact(_dot_)com>
To: "'Greg Connor'" <gconnor(_at_)nekodojo(_dot_)org>; "Harry Katz"
<hkatz(_at_)exchange(_dot_)microsoft(_dot_)com>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Saturday, April 24, 2004 8:52 AM
Subject: RE: Can you ever reject mail based on RFC2821 MAIL FROM?


From: Greg Connor [mailto:gconnor(_at_)nekodojo(_dot_)org]
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.

This may be true for altavista.com, but it is not true of domains in
general. Email service providers that handle bounces for their clients, as
well as numerous vertical applications, frequently have domains that are
used only for that purpose. The 2822 from domain is the sender, the 2821
domain is the bounce handler (with names along the lines of
"in.constantcontact.com"). In other words, there are domains that are
valid
in the 2821 from but never valid in the 2822 from.

This is true.  But statistically, 60-80% the 2821 is spoofed and detectable.
We have been doing it for the last 7 months in field testing with many sites
processing millions of messages.  The compliant rate is practically NIL.
The complaint rate is really the only way you can measure all this.  When
something is off - you get immediate feedback.

So what I am saying is that it is illogical to continue with a wasteful
transaction that may be detectable with RFC 2822 as well, but with not much
more benefits than rejection at 2821.   Can you should me how?

Now, if this rate was down to 5-10% or even 20-25%, then sure, you have not
choice but to continue with your transaction where a good system with have
the secondary defense in place.   But this is going to happen naturally
anyway because of a no-decision at SMTP.  It should not suggest getting rid
of your frontline defense at SMTP.

The 2821 address is the bounce and error handler. Checking the 2821
validity
tells you ONLY that there is a legitimate bounce and error handler for
this
message. It tells you nothing else.

What else do you want to know?

It tells you a lot.  Again 60-80% of it is spoofed or simply bad and if you
removed the issues related to concepts such as SMTP call back system and
perform raw testing for proof of concept you will see all this.   What LMAP
is proven is that it can help alleviate some of issues of falling back to
using a CBV, if  it widely deployed.

I can understand an argument for rejecting messages that don't have valid
return addresses, but I can't see that it amounts to much more than a
distraction on the route to creating accountability, which requires
validating servers and senders. A valid server and sender will provide (by
any reasonable definition of valid) a valid 2821 address.

The problem is the exploitation of the SMTP process.  By far, the MAIL FROM
is representative of the Originating Author. Of course, mailing list as such
are exceptions, but most industry email are person to person which is where
the SPAM problem is.

SMTP only needs compliant information. That's the best we can do at this
level.  Any more and we are beating a dead horse.    RFC 2822 can only help
at hop validation because the network control header, "Received:" is
mandatory. Once we solve the integrity issue with it, then we solve the
chain of trust problem.    Trying to use Mail control headers really can't
help much more because of legacy issues.  There is no real standard here.
Sure, it helps, no doubt. but not at the expense of your SMTP checking.
MUAs can solve the end-point to end-point ala Yahoo's Domain keys.  I see
this as a separate issue.  Besides,  who says I need mail control headers?
It doesn't display well in my cell phone email pager.  I have a
printer(_at_)winserver(_dot_)com that some our integrated services use.  I 
don't need
headers for that.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com