[AccuSpam]
Frankly I do not see this as a problem. If the domain for
envelope sender has declared "-all" in SPF, then if the
spammer forges the "From:", then anti-spam will use the fact
that "From:" and envelope sender (or Return-Path:) are not
the same, as another probabilistic measurement.
Well, I would argue that:
1) The IETF should not rely on a potentially unavailable feature of an
MTA or perhaps non-existent anti-spam filter to prevent phishing.
Whatever anti-forgery system is ultimately put forth by MARID/IETF, it
should protect against both envelope and header forgery. This could be
as simple as making SPF the standard, and then re-writing the RFC-2822
FROM header, and Sender headers, to be the same address.
2) Sender ID, for the most part, accomplishes both of these
authentications, since you are supposed to publish a classic SPFv1
record in addition to the SPFv2/pra record in order to comply with
Sender ID. So you get RFC-2821 and RFC-2822 protection.
Bankers are a funny lot. In the U.S., banking is a heavily regulated
industry. Bankers are not interested in "probabilistic" half-measures
such as you describe, they are interested in regulatory compliance and
repeatable, predictable results (be they financial or otherwise).
As such, I think the banking industry will only seriously adopt an
anti-forging technology once it is on the official IETF standards track,
and has notable success stories at preventing phishing and other
forgery. Bank of America, for example, probably has hundreds, if not
thousands, of internet-connected MTAs. Publishing SPF records is fairly
easy, but making sure that MTAs are upgraded, sending the correct HELOs,
etc. is not. Deploying SPF or SenderID or whatever will be non-trivial
in cost, and will take quite a while to accomplish with planning and
deployment in phases. Banks have to test the crap out of their IT
infrastructure, usually in a parallel mode, because the costs of
downtime and errors is so high. Their IT organizations do not want to
bear this cost multiple times.
Now, you might note that phishing probably costs BofA a lot more than
deploying 10 different authentication standards in a year. But the CIO
doesn't see that cost in his budget, the fraud department does, so the
CIO is content to wait for an authentication standard to come out. So it
goes in a large bureaucracy.
Regards,
Ryan