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

In <[email protected]> Douglas Otis <[email protected]> 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