On Nov 7, 2008, at 11:26 AM, J.D. Falk wrote:
On 07/11/2008 10:27, "Charles Lindsey"
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:
On Fri, 07 Nov 2008 04:00:58 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org
>
wrote:
New email headers' misuse of the term "authentication" will prove
highly deceptive for recipients and damaging for domains!
[ . . . ]
All you are doing is making a, possibly sensible, case for better
wording of the various parameters of this header. If you were to
concentrate on that, we might begin to listen.
Headers aren't UI. The vast majority of users never see a raw
header in their MUA -- it's always translated in some way,
prettified for their convenience. We SMTP nerds, who actually read
headers and understand what they mean, are a vanishingly tiny
minority. I won't even get into internationalization issues (well,
maybe in my signature below.)
If Doug wanted to make a positive contribution on this topic, he'd
team up with some user interface researchers and write a set of
recommendations for MUA developers. Continuing to rant about
renaming a header that users never see (and that is already in
common use across the network) is, clearly, a waste of everybody's
time.
J.D. Falk,
Nearly all MUAs or web clients for email permit users a ready means to
view headers.
For Apple Mail, it is View > Message > All Headers
When users become suspicious of a message, they are likely to examine
as much as they can, which of course includes the headers.
So now they see:
Authentication-Results: my-trusted-isp.com; sender-id=pass
jon-doe(_at_)example(_dot_)com
This header will deceive nearly all recipients into thinking that they
understand what this conveys.
The important identifier that should be checked against a reputation
database is not even included in this header. There are many free
public reputation sites that allow users to enter an IP address to
determine the present reputation of the MTA IP address. Having the
recipient check after the message has been delivered offers an
additional level of protection. It often takes several minutes
before IP reputation information can be collected and made available.
As was said many times, MTA authorization DOES NOT safely confer a
negative reputation for the domain!
It would be negligent of providers to expect recipients to know:
a) that jon-doe is never verified by MTA authorization, even when all
the involved MTAs impose PRA restrictions,
b) that example.com is confirmed as the source whenever a message is
carried by a shared MTA that does not impose PRA restrictions,
c) that most shared MTAs do not impose PRA restrictions,
d) whether the SPF record used was specifically intended to support
Sender-ID/PRA,
e) how to access the SPF and determine what type of use was intended.
Exploitation of this deceptive header is likely to force providers into:
a) disabling the inclusion of the header,
b) adopting proprietary PRA restrictions which may disrupt their
customers' email.
The best choice at this point is to ensure the header is much less
deceptive, and that it includes salient identifiers that users could
then make further inquiries about. As in the prior message,
Authentication-Results: my-trusted-isp.com; sender-id=pass
MTA/192.168.100.128/Authorized-By/@example.com
should significantly reduce the risk of deceiving recipients by making
it clear that the mechanism in play is authorization and that jon-doe
is not involved, but that the IP address of the MTA is.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html