Re: draft-schlitt-spf-classic-02.txt

In <[email protected]> Douglas Otis <[email protected]> writes:

> On Wed, 2005-06-08 at 21:12 -0500, wayne wrote:
>> Douglas Otis <[email protected]> writes:
>> 
>> The above language for "Pass" is actually somewhat less strict than
>> the responsibilities assigned in the draft-mengwong-spf-* drafts.
>
> The results remain unchanged. "Considered responsible for sending the
> message" represents an irresponsible conclusion.  What assumptions
> permit this conclusion?  Is it the domain owner that should know better
> than to trust their email provider?  Or is it the recipient that should
> know better than trust the mailbox-domain to be legitimate?  The
> statements in the introduction and what is implied by a Pass condition
> will result in considerable harm.

Well, SPFv1 has been deployed by thousands of domain owners since
early 2004.  After a year and a half of experience, only a very few
people seem to think this risk is significant.  I'm not going to
debate this issue with you since we have done so in the past and I see
no productive result of debating it again.


>> The draft-schlitt-spf-classic-* series of I-Ds is an attempt to
>> document what is, not what should or could be.
>
> This is not entirely true.  This draft can still recommend deprecating
> the use of version 1 records, and document how version 2 records ARE
> being used.  

The whole point of spf-classic-* is to document how SPFv1 is being
used.  From what I can tell, version 2 records *aren't* being used,
and therefore the MARID protocol *isn't* being used.



>> > The need for checking the HELO would be to protect network resources
>> > using a unified name reputation service. The potential for hundreds
>> > of DNS queries to resolve something as simple as HELO means this
>> > scheme has a rather basic flaw.
>> 
>> In theory, SPF HELO checking is far less than optimal, but in practice
>> it isn't that bad.  [...]
>
> The inordinate number of DNS lookups mandated by SPF to resolve a
> sizeable address list, when just a single host is being sought, pose
> serious indefensible risk.  Motivation to change this practice will
> likely become a matter of necessity at some point.

Ok.  I disagree, but I'll grant you an "I told you so!" if it ever
happens.




>> There are several reasons why people like SPF, limiting blowback is
>> just one reason.
>
> Wouldn't BATV provide superior blow-back (DSN notifications sent to a
> spoofed bounce-address) protection?  Unlike SPF, BATV achieves results
> when implemented unilaterally.  Just removing original message content
> in the DSN would also deprecate spoofing the bounce-address as a
> delivery ploy for spam or viruses.

You can use BATV if you want.  Personally, I think it is a poor
re-invention of the ABBS/SES wheel, but YMMV.

The point remains that limiting blowback is not the only reason people
like SPF.


>> > 2.4.  Checking Authorization
>> > ...
>> > ,----
>> > | Without explicit approval of the domain owner, checking other
>> > | identities against SPF version 1 records is NOT RECOMMENDED because
>> > | there are cases that are known to give incorrect results.
>> > `----
>> >
>> > Do you really think this sentence will cause a company to change their
>> > released version of Sender-ID?
>> 
>> I don't know, but I do think that it is important to let people know
>> about the dangers.
>> 
>> I think it is likely that developers will need to update their MARID
>> protocol implementations anyway.  Instead of using the marid-protocol
>> document, they are now using the spf-classic document, and these two
>> documents are not completely compatible.
>
> When you say MARID, do you mean Sender-ID?

Yes, when I say "the MARID protocol", I mean what was one called
Sender-ID on this list.  Andy checked with the powers that be within
the IETF and they said that another name should be chosen due to the
trademark conflicts with Sender ID.  I am simply trying to follow
that request.


I'm going to skip the rest of your message.  Again, these are old
issues that I don't agree with your assessment and I have better
things to do with my time than to repeat myself.


-wayne