ietf-mxcomp
[Top] [All Lists]

Re: TECH: use fetchmail algorithm to select header address to verify

2004-09-07 08:20:19

In <0AEC9791-00CD-11D9-9A6B-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton 
<andy(_at_)hxr(_dot_)us> writes:

On Sep 6, 2004, at 10:43 PM, wayne wrote:

As much as I would love to discuss this, the co-chairs are repeatedly
asked us to not discuss alternative proposals until such time as we
are finished working on the current I-Ds.

Wayne,

Is your proposal a different algorithm for using the headers?  Or is
it more than that?


It is a fair amount different than either the PRA or the fetchmail
algorithms.  I believe that protecting the From: header is *CRITICAL*
because it is the only thing that is usually shown by MUAs that are
out in the field today and that is what is needed to stop phishing.
As such, the only header that is checked is the From: header.

As has been pointed out many times, in a (vast?) majority of cases,
email is one hop, person to person, where the 2821.MAILFROM is the
same as the 2822.From:.  I such cases, there is no reason to check
anything other than that single email address and SenderID is already
the same as SPF-classic.

In the cases where the 2821.MAILFROM is not the same as the
2822.From:, most of it is due to some sort of forwarding/redirection
that the end user receiving the email has set up.  For example,
mailing lists and things like acm.org.  In almost all cases, it is
easy to identify something to whitelist on.  Many times, the end user
will not even need tell a spam filter/MUA about it, it can be
automatically determined.

My ideas about this stuff is actually heavily based on the way
SpamAssassin does its auto-whitelists.


There are cases that my method doesn't work very well on.  For
example, if a company outsources their email for things like customer
web orders and wants a different 2821.MAILFROM vs the 2821.From:, then
there is nothing to whitelist on.  I such cases, the company and ESP
will need to depend on an accreditation system.  Or, they could rework
how they are doing things so that the From: header will authenticate.

Also, stuff that is BCC'ed may need to fall back to far less reliable
things like the HELO domain.  The many different and ever-changing
list of valid HELO domains, however, can usually be collected via
normal traffic, so an automated system could detect such cases.


My hurriedly authored I-D can be found at:
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt

(This was supposed to be part of the Unified-SPF collection of I-Ds,
but I didn't get word from Meng not to submit it until too late.)


-wayne