John Glube wrote:
However, it also allows as Mark suggests non RFC compliant
sender?s to play games and chose the best algorithm to
inspect their message for their own purpose. Tilt.
The only difference between SPF/MAILFROM and the PRA stuff
are the checked headers. So if I'm Phred Phisher in Elbonia
(Mark's example) and phisher.com is my throw-away domain for
today, I simply publish...
"v=spf1 exists:%{ir}.comcast.blackholes.us -all"
...and let my zombies fire, MAIL FROM:<admin(_at_)phisher(_dot_)com>
Of course I also use a matching From:, because that really
looks better. But I could then replace v=spf1 by v=marid1,
if this results in a green blinking flag on the MUA of the
unlucky recipient, with a nice onmouseover text "IETF says:
admin(_at_)phisher(_dot_)com is a good phisher, trust us".
Or are you talking about a case where Phred Phisher claims
to send From: admin(_at_)paypal(_dot_)com ? That's not covered by
classic SPF, no green blinking flag on the MUA. With PRA
and v=marid1 I could use:
Sender: secure(_dot_)server(_at_)phisher(_dot_)com, From:
admin(_at_)paypal(_dot_)com
Now it depends on the MUA resp, the user, there should be
a green blinking flag, but _only_ for the Sender: address
secure(_dot_)server(_at_)phisher(_dot_)com
What will the users do in this case ? Are you looking for
a technical solution of social engineering ? I'm not sure
that this works, technical solutions for social problems
are really difficult, do you believe in say P3P ? I don't.
And if the recipient uses SPF/FROM-HDR _instead of_ PRA,
will he delete all mails with From != Sender ?
Whatever he does, it's not what my v=spf1 sender policy
wants: Get rid of the useless bounces to forged MAIL FROM
addresses, but don't do wild and wonderful things with 2822
headers incompatible with legacy software.
PRA with "default Sender:" could work with legacy software,
but so far nobody supports this idea. And there are some
interesting ideas in SPF/FROM-HDR not covered by PRA, and
incompatible with PRA. Sigh.
Bye, Frank