On Wed, 2005-06-08 at 21:12 -0500, wayne wrote:
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.
This draft still insists that by providing authorization for the server,
the mailbox-domain owner is "responsible for having sent the message."
How can you arrive at this conclusion without considering
"authorization" equivalent to "authentication?" How do you know the use
of the mailbox-domain is "legitimate?" You are assuming exclusive use
of the mailbox-domain is assured by the email provider.
This introductory paragraph must include a dire warning there will be
those that consider "authorization" equivalent to "authentication." To
protect the reputation of your domain, establish service level
agreements with your provider that indemnifies you, as the domain owner,
from the provider allowing non-exclusive use of your mailbox-domain,
whether for the bounce-address or the purported responsible address.
Those, in control of millions of zombies, will have at their disposal a
matrix of all possible mailbox-domains that authorize the outbound
server, detected by issuing a single message. Those servers shared by
many domains will be an exploit bonanza. This false assumption, which
goes well beyond what may be safely deduced from server authorization,
place a majority of mailbox-domain owner's reputation in peril.
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 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.
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 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 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.
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?
2.1. The HELO Identity
...
,----
| Note that requirements for the domain presented in the EHLO or HELO
| command are not always clear to the sending party, and SPF clients
| must be prepared for the "HELO" identity to be malformed or an IP
| address literal. At the time of this writing, many legitimate e-mails
| are delivered with invalid HELO domains.
`----
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.
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? It is unrealistic to expect
Sender-ID will change. There are real and inexcusable dangers created
by how the scope-less version 1 SPF record is interpreted. To insist
that documented methods in the use of SPF records must exclude the
scoped version of the record is nonsensical. This abstinence from scope
enables a Sender-ID reputation trap.
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.
The time lines of these decisions should not preclude becoming aware of
a problem created by a competing draft. Once aware of the results of
this capricious dismissal of a previously considered essential element,
act to reintroduce scope.
You should understand that publishing SPF records are not free from
risk, even without errors. Much of the risk occurs as a result of those
that mistake authorization for authentication. The domain supported by
server authorization can not safely be assumed to have originated the
message. While it could be possible to refuse messages that are not
authorized by an SPF record demanding strict compliance, this is really
not practical either.
The real use for SPF is to offer greater protection for bulk email
distributors by way of white-listing implemented by major providers. I
would even recommend that there be a scope devised, such as admin, to
specially limit the SPF record to this use. This would mean there are
NO assurances being made for any mailbox-domain anywhere within the
message. The domain owner simply wants to be trusted to do the right
thing and does not want to risk any contained mailbox-domain becoming a
victim of authorization-reputation.
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.
This version of the SPF record is also seen as applicable for the PRA.
For a brief period of time it was. The draft that includes this scope
for this early record also shares a common author. You are really in a
weak position to insist they are wrong and you are right. You will not
win this argument and harm those that believe otherwise.
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.
Once insidious applications creep in that base reputations upon PRA
authorizations, while using the Machiavellian user feedback, this will
become a very real problem. I can imagine it now. "We supply the
tools. These tools don't give mailbox-domains a bad reputation, people
give mailbox-domains a bad reputation."
-Doug