In
<1118346820(_dot_)7571(_dot_)140(_dot_)camel(_at_)SJC-Office-DHCP-156(_dot_)mail-abuse(_dot_)org>
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
On Wed, 2005-06-08 at 21:12 -0500, wayne wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> 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