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 
meaning.
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.
Picking PRA
-----------
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 
discussion.
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.

        - Mark