From: Ryan Malayter
Sent: Friday, June 04, 2004 1:35 PM
[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.
Actually, that was a suggestion on my part, so I'm glad it makes sense to
you. I really don't know what SPF2 is, but I hope people are open to doing
something like this.
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".
Yup, I completely forgot about these. Since they are mail redistributors
(the term used in the RFC's) as opposed to forwarders, they operate like
mailing lists so From: and Sender: are naturally different domains.
From my reading of the RFCs, this setup is semantically
correct, and would pass SPFv1, and even SPFv2 as proposed.
That's how I read them, too, and I can't see how it would fail SPF.
However, the address in the From: header is untrusted since it cannot be
validated. This is no different from any mailing list. As I suggested in
another post, and along the same lines of Shevek's suggestion, the MUA
should probably flag the From: field as unverified unless it bears a crypto
signature or is verifiable by some other means. As others have pointed out,
a certificate can be a forgery, so that isn't a panacea, either.
BTW, what exactly is SPF2? Is it SPF1 after flag day?
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.
Completely agree. Your domain is the responsible sender, but you are
sending the message on behalf of someone from another domain.
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. ;-)
That's the problem I see with it as well. Unfortunately, they probably
aren't aware enough to even ask the question.
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.
Clever social engineering is hard to overcome. Always was, always will be.
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.
There will always be scammers as well as people who believe in things that
are too good to be true. The goal of authenticating more of what the user
sees in the MUA is to tip the scales away from the scammers, so that average
users have a better chance of realizing they are looking at a scam. We can
give them the information but they still have to make the choice. Until we
provide users with useful clues, the scammers definitely have the advantage.
--
Seth Goodman