Ryan Malayter wrote:
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.
Michael R. Brumm wrote:
SPF protects envelope forging correctly. SenderID doesn't.
While SPF doesn't prevent forging of 2822 addresses seen by 99% of MUAs,
the
same could be said of SenderID. I don't know of any MUAs which display the
PRA as described by SenderID.
Rand Wacker wrote:
As I said before, there is a large majority of mail that goes from large
commercial sites (or consumer ISPs) merely one hop to another large
commercial ISP, so the From: header will be successfully authenticated.
The problem with SenderID I mentioned is that most of the other PRA fields
(besides From:) are invisible in most MUAs, and therefore allow forgers to
spoof the From field anyway. The solution to this problem is, of course,
upgrading MUAs to display the PRA field. But according to Ryan, SenderID's
improvement over SPF was that MUAs didn't need to be upgraded.
I'm not sure how the number of hops or the business model used by the MTAs
affects this.
In any case, if we are talking about upgrading MUAs en-masse to combat 2822
header forging and phishing, then I think the only good solution is
cryptography and signing. However, this is probably outside the scope of
MARID.
Michael R. Brumm