[Seth Goodman]
That gets rid of the Sender parameter. Sender is
automatically validated when we validate MAIL FROM:
on the first hop.
The new SPFv2 RFC will ensure that this is the case, right? That the
"Sender:" header must equal MAIL FROM? I hadn't seen that detail
discussed anywhere, but it makes sense so maybe it was obvious to
everyone but me.
OnBehalfOf is really the From: header and that's a
sticky question. Does anyone outside the same
domain _really_ send mail in anyone else's behalf
anymore, aside from mailing lists?
The case I was thinking of were a couple that I face myself:
1) A "send this article to a friend" function on a
website. This is used quite frequently. Currently,
we set the envelope sender to webserver(_at_)websitedomain(_dot_)com,
set the RFC-2822 "From" header to the third-party visiting
our site, and set the RFC-2822 "Sender" header to
"webserver(_at_)websitedomain(_dot_)com".
From my reading of the RFCs, this setup is semantically
correct, and would pass SPFv1, and even SPFv2 as proposed.
We want the recipient to recognize that the hosting
organization is not sending spam or anything, that the
article was sent at the request of another party, which is
why that third party is in the RFC-2822 "From" header.
Putting the website domain in the RFC-2822 "From" header
with a message in the body or subject stating
"user(_at_)somedomain(_dot_)com requested that you be sent you this
article" is an option. But it could still lead to the
recipient marking the emailed article as spam, because it's
from someone they don't know, and the website domain could
(unjustifiably) end up in RBLs.
2) A third-party customer survey or something, which we have
done in the past. But presumably this could be taken care of
by adding the surveying organization's MTAs to our SPF
records in advance. Getting the line-of-business folks that
engage such surveys to notify IT in advance is problematic,
but certainly beyond the scope of SPF. ;-)
A phisher could always just use something like:
"From: "First National Bank Customer Service"
<someguy(_at_)phisher(_dot_)com>"
This type of phish would probably somewhat be effective as well, and I
can't think of a fix for it. Even Domain Keys wouldn't help, presuming
phisherdomain.com was new and hadn't been blacklisted yet. S/MIME or PGP
would only help if the user checked the trust path of the certificate.
But I can't get my user population to do that for shopping web sites,
much less for every email.
I think phishing prevention is a matter of education; technical
solutions can only go so far - even full cryptographic ones. That said,
it would be nice for SPFv2 to do as much as possible, allowing for only
one or two types of phishing attacks (e.g. throw-away domain or display
name that doesn't match the email address). That would make the
education piece easier.
Regards,
Ryan