Re: Is the back door open?
It has taken me a few days to digest and understand the broad range of
concerns with Sender-ID that Doug has raised. Most of the specific
points already have clear responses by others in this thread. I hope
to respond to grander concepts implicit in Doug's statements.
Picking an Identity
This group has agreed up front that a piece of the spam puzzle hinges
on being able to check that the sending MTA's IP address is authorized
by the domain of some identity associated with the e-mail message. By
holding that domain responsible, and staking it's reputation on the
actions of the MTAs it authorizes, the scheme enables systems that
result in a reduction of spam.
For better or worse, RFC 2821 and RFC 2822 are not concerned with this
kind of identity. Due to both the design of the standards, and
deployed current practices, none of the identities: not the HELO
domain, not the MAIL FROM, nor any of the headers, presents a clear
identity of the form we need.
The schemes discussed in this group, CSV, original SPF, and Sender-ID
each pick an identity from the RFC 2821/RFC 2822 set and imbue it with
the meaning we need. We expect that upon adoption of such a scheme, by
virtue of being checked by receiving MTAs, it will acquire this new
However, by doing so, the new scheme will be at odds with some segment
of current practice, and cause some entities to change their processes.
Picking an identity is a matter of weighing pluses and minuses - there
is no clear choice.
Originally, SPF was based on the 2821 MAIL FROM identity. Briefly, it
is a convenient identity to check, and it had the additional advantage
of directly confronting bounce-back attacks ("joe-jobs"). However,
downsides were that it requires some significant changes for some MTAs
(in the form of SRS) and that this identity isn't generally connected
with anything the recipient sees.
Picking an identity based on the 2822 headers is closer to what
recipient thinks of as the identity and can require fewer and simpler
changes for MTAs that need them (in the form of SUBMITTER).
The current form of the PRA algorithm (in core-02) is neither heuristic
nor proprietary nor arcane: It is a direct embodiment of the 2822
concept of the mailbox that sent or resent the message. The priorities
and orderings of the headers checked is follow directly from the 2822
definition of the headers. I'm sure the description in core-02 could
be more clear in this regard.
One minor related issue: Multi-part messages have no bearing on PRA,
since the MIME multi-part construct, including the headers of any
included messages, is all part of the body of the outer message. Such
attached headers are never involved.
DNS DDoS and Other Attacks
The number of DNS queries has been grossly overstated in this
As for DDoS attacks based on SPF records designed to cause large number
of DNS queries, or through excessive querying of legitimate SPF
records, this is discussed in the protocol draft. In short, while
conceivable, the possible DDoS attacks are harder to mount and have
less impact that other, existing mail based DDoS attacks.
It seems to me that ALL schemes discussed in MARID are subject to DNS
poising schemes. Indeed, we talk about it clearly in the protocol
draft. This is nothing new.
The notion that SPF computation is so high that that sites will
postpone the Sender-ID check until the receiver is a known good user
does not hold up to scrutiny. Large volume mail receivers routinely
apply checks that are far more resource expensive than Sender-ID.
The vulnerability of sending via backup MXs is there in EVERY scheme -
and exists today -- no one can really use backup MXs that aren't under
their administrative control, and aren't configured to support the
identical local mail policy. The era of reciprocal friendly back-up
MXs is gone. However, deploying secondary and backup MXs within an
organization, with common administrative control and policy still works
in the face of Sender-ID. And yes, the Sender-ID check needs to be
done at the border, as do any checks that are checking the
authorization of the sending MTA.
Yes - Sender-ID no longer directly combats bounce attacks. But it does
insofar as the only bounced mail is mail that doesn't fail a Sender-ID
check (as that mail would be rejected at the 2821 layer.) Of course,
the reputation of the domain in a message that passes Sender-ID stakes
its reputation on the message and hence if the bounces are joe jobs, it
would suffer. Does this mean that anyone launching a bounce attack
will use a domain without a published SPF record? Yes - but no scheme
proposed on MARID purports to break the status quo. And, when I
discuss my work with anyone, bounce attacks are at the bottom of the
pile of spam concerns.
Lastly, neither Sender-ID, CSV, nor original SPF will stop phishing
directly: Once a phisher catches own, they will have domains set up
correctly. Only the addition of reputation can fix this, and then only
if MUAs present the information in a way that users can understand.
"big-bank.cc" is going to be forever confused with "big-bank.com".
Sender-ID however helps the most: Since it is based on the reputation
of a domain the user will see, and we can only hope the "big-bank.cc"s
of the world will get a bad reputation quickly.
I hope this helps further our group understanding.