Re: Email Forwarder's Protocol ( EFP )

At 01:19 PM 2/26/2005 -0500, Stuart D. Gathman wrote:
> On Sat, 26 Feb 2005, David MacQuigg wrote:
> > At 12:08 AM 2/26/2005 -0500, Stuart D. Gathman wrote:
> >
> > Seriously, though, if the IETF came to you and said, were finalizing a
> > standard for email authentication in 30 days.  We're going to pick just 
> one
> > proposal of the many that are before us.  What is your nomination?
>
> SPF + SRS(opt) + SES(opt)
Won't this be opposed by Microsoft and by the anti-SPF crowd?  Do you think 
such opposition can be ignored in a standard, even if the opponents motives 
are questionable, and their arguments are technically incorrect?  If 
opposition is ignored, will the standard be rapidly and enthusiastically 
adopted by domain owners worldwide?  These protocols may be technically 
perfect, but the social engineering has so far been a failure.
> > My nomination would include only three header items:  The IP address, the
> > authenticated domain name, and the authentication result.  Standardize
> > that, and you can debate the rest forever.  The IP address is already
> > nailed down in RFC 2821.  That leaves the only two items that anyone could
> > object to.  Note:  We don't need to debate the protocol for determining
> > which domain name to use.  That can be protocol-specific.  Details of
> > formats are too trivial for a debate.  About the only thing I see that is
> > debatable is the authentication result. ( How many different levels of
> > SoftFail, etc.).  As a last resort, if no agreement can be reached by day
> > 29, then each protocol can use its own words, like SPF1(SoftFail).
>
> Your email authentication proposal is probably fine, if I were to look at
> it in detail.  The reason I am dismissive is that you have not mentioned
> anything that would make it functionally different from SPF + SRS.
> SPF + SRS have been in production for over a year now, with over 200000
> domains in the registry.  Spammers are adopting it also (which is fine,
> SPF is *NOT* a spam filter).  There is no reason to study your proposal
> unless you can convince me that it solves some problem that is
> not addressed by SPF + SRS + SES.  And if you *were* to identify such
> feature, I would push to add your idea to SPFv2 or whatever, rather
> than abandon the highly successful and effective SPF protocol for
> your untried system.  The problems you have identified with SPF have
> not been with SPF itself, but with some implementors (e.g. pobox.com)
> not actually checking it.
Again, the focus should be on social engineering, not the technical 
advantages of one proposal over another.  I'm not saying there is some 
technical problem with SPF/SRS/SES.  What I am suggesting is that we find 
some common ground that all sides can agree on ( or look very bad if they 
don't ).  Then we can get a common standard approved, even while 
competition proceeds on the implementations of that standard.  With a 
universally accepted "email authentication standard", we might break the 
current deadlock.   More domains will start using authentication, and 
pushing on the domains that don't.  Companies like SpamCop that now have a 
very low opinion of SPF and email authentication in general, will start 
producing domain-rating lists.  Those lists will get used in filtering 
spam, putting more pressure on non-conforming domains.  If we do the social 
engineering right, we will reach a point of "positive feedback" in the 
adoption process, and it will go to completion.  By "positive feedback" I 
mean, that the immediate benefits of adoption exceed the immediate costs 
for the owners of almost all legitimate public mail servers.
Let me pose a different question.  If a standard were adopted, and that 
standard included only the three items I suggested ( IP address, domain 
name, authentication result ), would the SPF community be able to work with 
that?  e.g. would you be able to produce an MTA that did authentication the 
way you want, even putting other information in your own headers, but still 
work with other MTA's that might use SenderID, or some other protocol that 
communicated authentication information only via those three items?  I 
notice that SRS uses a hash code.  That isn't part of the standard, so your 
MTA must work even with another MTA that doesn't use it.
-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com