In
<1118258112(_dot_)7583(_dot_)68(_dot_)camel(_at_)SJC-Office-DHCP-156(_dot_)mail-abuse(_dot_)org>
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
1. Introduction
...
,----
| An additional benefit to mail receivers is that after the use of an
| identity is verified, local policy decisions about the mail can be
| made based on the sender's domain, rather than the host's IP address.
| This is advantageous because reputation of domain names is likely to
| be more accurate than reputation of host IP addresses. Furthermore,
| if a claimed identity fails verification, local policy can take
| stronger action against such e-mail, such as rejecting it.
`----
2.5.3. Pass
,----
| A "Pass" result means that the client is authorized to inject mail
| with the given identity. The domain can now, in the sense of
| reputation, be considered responsible for sending the message.
| Further policy checks can now proceed with confidence in the
| legitimate use of the identity.
`----
This is where SPF and Sender-ID make a very serious mistake. This
assumes "server authorization" is equivalent to "sender authentication."
This has been discussed many times on the spf-discuss list. The
general consensus is that "server authorization" is *NOT* equivalent
to "sender authentication" and that is why the SPF-classic I-D uses
authorization throughout.
It would be like me making a declaration that the postal service is
authorized to deliver my letters, where recipients are then claiming any
letter received from the postal service bearing my name is authentically
or genuinely from me. Of course that would be a false assumption, yet
this draft describes the sender as "considered responsible for sending
the message." Review the many assumptions being made before arriving at
this conclusion. This false assumption is also why publishing SPF
records is unwise for the majority of domain owners.
The above language for "Pass" is actually somewhat less strict than
the responsibilities assinged in the draft-mengwong-spf-* drafts.
2.1. The HELO Identity
There is an expression, when your only tool is a hammer, everything
looks like a nail. While checking the HELO may extend the use of name
reputation into the initial exchange, the use of SPF to confirm the HELO
is using a rather heavy hammer.
Indeed it is a rather heavy hammer. No question about that. If you
could loan me a time machine, I would be quite willing to go back to
the fall of 2003 when this was first set up.
Unfortunately, this kind of HELO checking has been in place for a year
and a half now, there are lots of people who have published SPF
records under their HELO domains, and there are lots of people who are
checking these HELO domain SPF records even when the MAIL FROM is not
null. (i.e. SpamAssassin)
The draft-schlitt-spf-classic-* series of I-Ds is an attempt to
document what is, not what should or could be.
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. Since you should publish SPF records at your HELO
domain if you publish SPF records at your MAIL FROM domain, a lot of
people are going to be publishing them. It is not clear to me that
any other system is enough better to motivate people to switch.
The prior justification for attempting to resolve the HELO was limited
to the handling of a DSN message with a null MAILFROM. With SPF failure
expected in this case, wouldn't something like BATV be more effective in
this situation?
Why would SPF failure be expected in this case?
There are several reasons why people like SPF, limiting blowback is
just one reason.
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.
I fail to see the justification for not offering a positive means to
express the scope of the record.
Mark Lentczner was the one who convinced Meng to remove the scope=
modifier from the SPF spec in the fall of 2003. Hindsight is 20/20.
Depreciate the version 1 record. Both
SPF "new classic" and Sender-ID may continue to utilize these older
records.
I see no particular reason why SPFv1 records should be depreciated.
They are well defined for the MAIL FROM and HELO identities which they
were published for.
There have been many technologies thwarted by a large company's ability
to dictate the definitions they promulgate. A large company may not be
right or fair about their selection. Something as simple as data
compression caused sizeable losses by a last minute imposition, even
when eventually adjudicated as unfair. Accept this banal reality.
Yes, that is possible.
My admittedly limited data shows that almost no one is checking things
for the MARID protocol. At this time, it doesn't seem to be a
problem.
-wayne