mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04

2008-11-07 19:02:13

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 
<Prev in Thread] Current Thread [Next in Thread>