In <792DE28E91F6EA42B4663AE761C41C2A02CEB944(_at_)cliff(_dot_)bai(_dot_)org>
"Ryan Malayter" <rmalayter(_at_)bai(_dot_)org> writes:
[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,
Yeah, but SenderID doesn't protect the From: header in any critical
situation. It protects the nearly invisible Resent-Sender: header.
and why Meng and
MS decided to merge the best parts of SPF and Caller ID into SenderID
approaches.
I have had lots of conversations with Meng and his usual reason for
supporting the merger was because he felt that MS would promote
deployment. He is now very actively promoting Unified-SPF.
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.
SPF-classic goes a long way of solving the forging of the
2821.MAILFROM identity. SenderID does not do much of anything to
solve the problem of forging the 2822.From: identity.
Even "Unified SPF" still defines the PRA algorithm for use in verifying
mail headers, and therefor is also incumbered by the Microsoft IP.
And the PRA part of Unified-SPF is optional.
-wayne