ietf-mxcomp
[Top] [All Lists]

RE: (DEPLOY) In Support of Sender ID

2004-09-02 13:36:24

On Thu, 2004-09-02 at 13:01, Ryan Malayter wrote:
[Kevin Peuhkurinen]
To my mind, there are ZERO hinderences to Microsoft 
adopting SPF, but there are plenty of hinderences 
for most everyone else to adopt the encumbered 
Sender-ID.

SPFv1 does not address email header forging at all. So SPFv1 does very
little to prevent forging of the "from" addresses seen by the user in
99% of MUAs. SPFv1 therefore does very little to prevent phishing scams.
This is why Microsoft came up with CallerID for email, and why Meng and
MS decided to merge the best parts of SPF and Caller ID into SenderID
approaches.

So yes, there are very big hinderances to MS and everyone else adopting
SPF classic - it doesn't solve a big part of the email forging problem.

Even "Unified SPF" still defines the PRA algorithm for use in verifying
mail headers, and therefor is also incumbered by the Microsoft IP.

I have introduced the MPR draft to illustrate how to arrive at either
the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building
upon the CSV standard to achieve the same goals as both SPF and
Sender-ID.  This does not use the PRA algorithm, as it expects From
restriction to be made for exceptional uses.  This also overcomes
problems of the indeterminate and potentially very high DNS overhead,
replication of DNS addresses, "open" lists creating spam exploits,
dangers of harm by misapplication of reputation, and removes an ability
to hide listing by way of macros.  One fundamental difference is the
treatment of reputation as a separate function from that of mailbox
domain to outbound server association.

-Doug