Shevek wrote:
On Fri, 4 Jun 2004, Daniel Quinlan wrote:
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com> writes:
Yeah! customerservice(_at_)bigbank-phisher(_dot_)com sent me an email and
bigbank-phisher.com says that it's actually an email from
bigbank-phisher.com! Nevermind the fact that bigbank-phisher.com is NOT
bigbank.com.
No, the problem is that you can give SPF-correct information in the SMTP
envelope, set one or two non-displayed headers (Sender, Resent-From,
etc.) to be correct, but then set From: to be bigbank.com. Since From:
is not checked under the SPF/Caller-ID merge and since not all MUAs
display from, then it seems to be from bigbank.
Given that the purpose of SPF was to prevent joe jobs, why are we having
this discussion?
When you have a hammer, everything looks like a nail.
In this case, we seem to have a nail, and SPF has a hammer costume on. But
it isn't a hammer.
SPF is necessary but not sufficient to prevent joe-jobs as it currently
exists. If you do _not_ do something like SPF, protection is unavailable.
The problem with these examples is that there is no requirement of a
relationship between the envelope-From and From:. To force such a
relationship breaks an awful lot, but even the wonderful cryptographic
authentication solutions don't fix the trust problem, so where
does that leave us?
Establishing trust relationships when the people intended to
be protected by the trust aren't willing to make an effort
to protect themselves is _impossible_ regardless of the clever
mechanisms you come up with.
SPF is a very powerful tool for those willing to make the
effort to use it effectively, and as such can help protect the
lazy victims by culling the herd of the lazy scammers.
--
Daniel Taylor