Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

In <[email protected]> Keith Moore <[email protected]> writes:

>>> all of the authentication schemes I've seen suffer from one or both of
>>> these problems:
>>>
>>> -  trying to do more than is reasonable for that particular approach
>>
>> This seems to be a pretty subjective criteria.  I suspect that
>> reasonable people can disagree on what might be considered
>> "reasonable" for a particular approach.
>
> yes, there will be some disagreement, but the opinions will often
> cluster in one general area, and you can get rough consensus on them.
> this does require engineering judgment.  it's not as if, for instance,
> there are objective criteria for how many DNS lookups are too many to
> use to validate an email address, but you'll get general agreement
> among most knowledgeable folks that there's a limit to how many
> lookups is reasonable, and those opinions will cluster around some
> compromise number.

Two comments:

First off, the SPF spec was developed in just such an open and mostly
by consensus manor.  However, you ignore the possiblity that instead
of one cluster, you may have several different clusters.

Secondly, there is an objective criteria for the number of DNS
lookups: "The number of DNS lookups must be limited to the point that
SPF can not be effectively used for DoS purposes".  (Most seriously,
on third parties.  That is, not the owner of the domain with the SPF
record, nor the receiving MTA, but someone that the SPF record
targets.) 

One of the changes I made to the current draft is to impose limits
first added to my libspf2 implementation, about a year ago.  This *is*
a significant change to the draft since most SPF implementations
didn't not have these limits, but I consider such a change important
enough to justify the breakage that happen.  I think it is simply
unacceptable to have a standard that allows for DoS attacks on third
parties. 


>>> -  trying to retroactively change how the mail protocol is used, or to
>>> restrict future use of the mail protocol such that valid use cases
>>> will no longer work
>>
>> Well, current SMTP specifications allow for anyone to use any domain
>> in either the rfc2821 identities, or any place in rfc2822.  All
>> authentication schemes intend to change that.
>
> it's tempting to respond that all of these authentication schemes are
> therefore "broken".  but that's so simple a statement that it's likely
> to be taken the wrong way.
>
> part of the problem is that none of the existing fields in either SMTP
> or [2]822 are intended to hold an authenticated ID of the originator,

Agreed.

> with the possible exception of Sender, even that one isn't well
> defined enough (or consistently implemented enough) to use.  and for
> every one of those fields there are numerous valid use cases for that
> field not being an authenticated ID for the originator, even though
> you might want to authenticate the message.  we simply don't have a
> field for that purpose defined at present.  various authentication
> schemes try to work around that by constraining or overloading
> existing fields.  the goal in doing so is to ease deployment, but what
> it actually does is limit the scheme's applicability.

The reason for wanting to authenticate the fields isn't just "ease of
deployment".  I don't even think that was the primary reason.

Many domain owners want to have some control over how their domain is
used, and many email receivers wish to listen to the domain owners.
Both snail mail and email allow anyone to put any name as the return
address and on the letter head of the letter.  Sometimes this isn't
abusive, but sometimes it is.  Making a letter/email look like it
comes from "Big Bank" when not authorized by "Big Bank" can get you in
legal trouble.  With email, and the various email authentication
systems, "Big Bank" can take technical steps, instead of just legal
steps, to prevent this.


-wayne