In
<C6DDA43B91BFDA49AA2F1E473732113E5DBB68(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
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.
[explains the real concern about phishin: loss of consumer confidence]
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.
It is not at all clear to me that the concerned people will download
an upgrade in order to see the validated headers in the MUA.
Corporate policies may prevent such an upgrade, as may software
incompatibilities or the need to upgrade hardware. Add to that the
general lack of knowledge of what the upgrade might do and how to
actually do the upgrade, and you have a very slow upgrade path.
Consider the number of email worms that are still wandering around
using exploits that have been discovered and fixed many months, or
even years ago.
I think that upgrades to MTAs will be done much quicker, but I still
expect that to take years.
My guess is that the software that is quickest to be updated is the
anti-spam and/or anti-virus software. While such software is flexible
about where it runs and what it checks, it can't change what the MUA
will display except in the crudest of methods.
The more I think about the issue of RFC2822 validation, the more I
think that only the validation of the From: header will restore
consumer confidence and that validating other headers instead may
actually hurt it if there is a false sense of security.
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.
Well, I guess then if I was able to dictate the work on MUAs, I would
say to put the effort into making S/MIME more useful rather than some
other scheme.
In a different message PHB writes:
Sure we can get carried away and do a full rigorous academic
research project here, but this tells me what I need to know, we are
at about 80% compliance and we can get to 95% compliance by addressing
one software platform and one service. That looks pretty encouraging to
me.
This may be a case of seeing the glass as half empty or half full. I
looked at the numbers and felt that even a 5% false positive rate on
mailing lists is going to be unacceptable to many, and it may take
quite a bit of work to get that far.
Instead of depending on the Sender: header, I would say it would be
far more effective to depend on the Return-Path: header (e.g. the MAIL
FROM). Sure, with stuff like VERP and SRS, the local part of that
email address is going to look real ugly, but I suspect that using
just the domain part would be all that most people would need.
But then, I'm still leaning toward S/MIME as the better solution.
Maybe header checks would be ok as a fall-back.
-wayne