Well, this gets back to the "user experience" thing. I am not very
comfortable with the idea that vast majority of users will not see the
validated header until they upgrade their MUA. This leads me back to
saying that if we are going to validate the RFC2822 data, we need to
validate the From: header, not the Resent-* headers, and probably not
the Sender: header.
Well first let me explain what the real concern is that has been raised
by the phishing spams that impersonate banks.
The issue is not actually the direct loss. At this point the banks believe
that the majority of the loss falls on the banks and MOTO merchants rather
than consumers and this particular loss is not large compared to phishing
fraud in general.
The biggest phishing fraud losses by far are due to spam that looks like
spam and does not impersonate banks. We know that certain spammers have
convictions for cocaine trafficing and money laundering. Would you
trust those people with your CC number?
The real issue that is being raised is loss of consumer confidence. That
means that many people are becomming less willing to use the Internet.
That in turn threatens a multi-billion dollar investment the banks have
made in deploying Internet based service delivery technology. The
direct losses are significant, probably running in the millions for some
parties. But the indirect losses threaten to be billions.
So in this particular context the ideal solution would be 100% backwards
compatible. But a solution that requires a software upgrade may well
be acceptable since the concerned people will download the upgrade.
As fraud goes impersonating a bank is a pretty clueless one. Its like
renting a billboard outside the Hoover building and saying 'We are
going to defraud banks'. It gets attention. There have been several
prosecutions already and more cases are in progress.
The directOnly attribute lets sending domains to declare
that they don't
*knowingly* send mail via mailing lists [or mail forwarder].
While I think it pretty safe for folks like paypal to assume that the
mail they send rarely gets sent directly to mailing lists, I think a
non-trivial amount gets sent to email forwarders.
I think we may need to tweak the semantics. But from a pragmatic
perspective the processing rules for any proposal we make are going
to end up in flux for a long time.
That is why I prefer that we adopt a declarative approach.
* The IP address of my outgoing mail servers are X, Y, Z
* I am / am not a frequent impersonation target of phishing fraud
* I am accredited by P, Q, R
So I don't like the 'direct only' semantics, I think they are too
restrictive, mail forwarding is OK provided that the recipient can
authenticate the forwarding relationship. But the wider sense of
'be very restrictive in applying the rules to this domain' seems
to be a good plan. It may not end up changing the flow chart but
I would expect that the spam assasin scores for failing authentication
would be very different.
I guess this leads me back to the question: Why not S/MIME with a
flag in the DNS somewhere that says "this domain always uses S/MIME"?
(Or GPG, or something similar.)
I think that would be a useful attribute to provide. We should make
sure MARID can be extended to support those semantics. But first
we have to do a lot of cleanup work on S/MIME. Even though S/MIME
was designed with the average user in mind to a much greater extent
than either PGP or PEM it still has a long way to go. It is not a
standards issue, it is a user interface issue.
I am hoping that at some point the solutions committee of
antiphishing.org can establish a relationship with members of the
MARID and ASRG lists. At this point however we are only just
getting started.
Phill
[Chair of the antiphishing.org solutions committee]