Scott Kitterman wrote:
Does it have value to give senders an option to say the
from==mailfrom for their domain so feel free to reject
anything where from!=mailfrom if the from is for their
domain?
From my POV it doesn't, I use From: nobody(_at_)xyzzy or other
local parts everywhere, e.g. in NetNews and mailing lists,
and news2mail or other gateways should keep the header of
the transported message as is as far as possible.
Some domain owners not interested in other protocols might
feel comfortable with restricting the uses of their domain
in mail header fields. Especially if they are the target
of phishing attempts.
Checking this at the MX is dubious, unlike SPF working at
the HELO or MAIL FROM phase, or maybe at the RCPT TO for
ideas like the "forward masterplan" and VARA, checking
obscure "anti-phishing equivalences" works only in the
DATA pase.
If you get to the DATA there are tons of efficient tests,
mixtures of SURBL, clamav, SA, DKIM, Sender-ID etc. And
I don't see where some op=from (or elaborated eh= ideas)
could significantly improve the existing mix (at the MX).
Behind the MX (MDA or MUA) it's already too late, because
you can't reject suspicious mails anymore, you can only
tag it, with all known side effects like false positives
deleted together with the real crap.
IMHO "phishing" is social engineering, for each hole you
(try to) fix the "phishers" find two new attack vectors,
it is more or less hopeless.
Of course a MUA indicating "something might be fishy with
this mail" would be nice, but it can do this without SPF
and new modifiers. E.g. if it automatically displays the
Return-Path in addition to From (+ Sender) when necessary.
For heavily phished domains I think it would be worth it.
I can certainly understand why they desperately want some
solution, it's like us desperately wanting no more bogus
bounces.
[ BTW, after about two weeks "my" spammer gave up again,
either because he found that forging SPF FAIL protected
addresses is a bad idea from his POV, or it was only a
test, or he picks forged domains by a private scheme for
relatively short periods. ]
But for receivers phishing is relatively harmless, most of
the time it's immediately clear, I don't have accounts at
$bank or ebay, and I'd also see it immediately if it's my
bank / paypal / firstgate / amazon / etc. where I have an
acoount, but certainly not as nobody(_at_)xyzzy(_dot_)
Because it's generally obvious I also report it a.s.a.p.
Therefore the "phisher" is blacklisted within minutes, and
"traditional" methods (neither SPF-modifier nor DKIM) will
catch this crap.
It's very rare that I get an (obvious) phish not already
tagged as ***SPAM*** by my mail service provider. Or in
other words, from my POV the phishing problem is not very
interesting, it's the same as "Viagra", it's just spam.
OTOH the question of "misdirected bounces" is a technical
issue of SMTP, and SPF FAIL can really help. Getting a
solid base for "reputation" (better than only DNSBLs, or
in other words RHS lists) is another technical issue where
SPF HELO tests (and in theory CSV) can help.
For "phishing" I doubt that SPF has much to offer, and I'm
far from sure that it's really a technical problem, it's
"only" one form of "social engineering".
So why don't the legit senders use S/MIME for their mails ?
Why do we discuss complex eh= and simple op=from constructs
instead of a hypothetical op=smime (= always S/MIME) ?
Above all, who needs DKIM and for what purpose ? Bye, Frank