ietf-dkim
[Top] [All Lists]

[ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations

2010-08-15 00:08:56

I intially saw a need for a MUA considerations because:
* I still hope DKIM will help protect email identity
* end users rely, or should rely, on their MUA to present verified identity 
information in an easily digestable way.
* MLMs break signatures and MUA will still need to present verified identity
* List identity is important to users as having no differenciation at the MUA 
between broken list signatures and phishing email
* List identity can be acheived with list DKIM signatures (as recommended) 
potentially coupled with a LDSP proposal that Hector mentioned. 
* MTAs at gateways are incapable of reliabily determining an individual end 
users' mail subscriptions.

If users are to place value in From headers as MUAs display and ADSP tries to 
enforce then manguling From headers is adds complexity to the interpretion of 
the header field by to the end user.

The advent of this draft as a informational standard, combined with ietf-marf-
dkim-reporting and RFC5451(Authenticated Results) and the desire to make dkim-
friendly lists will drive the dominate scenarios in the future.

Looking at a fingerpring mail client survey[1] survery it seems that the 
occurance of a few major web based email clients accounts for 35% of email 
traffic. Assuming a consistant correlation with email list subsribers there 
are a potentially a number of DKIM/list incompatible behaviours that can be 
rapidly adapted at the MUA. Even excluding the webmail suppliers the number of 
MUA vendors is quite small and therefore adaptable to the current need. The 
webmail MUAs can rapidly change to give the user the identity information that 
they need to identify orginal domains and a number of these are driven by MLM 
and DKIM considerations.

As such here is a proposed annex to draft-ietf-dkim-mailinglists that 
corresponds to Murray's request in the response to the first review request  
in the hope that MUAs will provide the valuable identity information that DKIM 
provides even in the presence of MLM.

[1] http://fingerprintapp.com/email-client-stats

ANNEX A - MUA Considerations

The main body of this document describes a number of MLM behaviours that break 
DKIM signatures. These behaviours are, in some cases, features required by MLM 
operators to forfill technical, policy or legal requirements. Some of these 
behaviours operate in such a way that breaks DKIM signatures and have 
alternate implementations that will also meet the needs of MLM operators.

Header Footer additions

Header/Footer additions on MLM can include unsubscribe information describing 
to the user how to unsubscriber from a MLM

MLM are recommended by LIST-ID to include a List-Unsubscribe header field. In 
the presence of MUA support this would depreciate the necessity of  
Header/Footer additions for unsubscribe information.

MUAs are recommended to present to the user the List-Unsubscribe header field 
URL in such a way that they can utilize this URL easily to unsubcribe from the 
email list.

Subject Header Modifications

A reasonable number of MLM list subscribers potentially still recognise and 
filter messages based on the subject line. The subject line modification is as 
effective as a List-ID filtering and MLMs are recommended to include this 
header field.

A MUA could implement the following features to reduce the need for signature 
modifications: 
* Display of the List-ID header field is used to be displayed beside where a 
subject header field is displayed.
* functionality to create a filter based on based on the List-ID header field.

Authenticated Results

[AUTH-RESULTS] describes how a MUA could use the Authenticated-Results heaader 
field to present DKIM validation information to the user. This is particularly 
important where the presence of broken author domain signatures are present 
and the presence of MLM dkim signatures may be used for alternative 
authenticity or filtering determinations.

A MUA could use the Authenticated-Results header field to:
* Display what authentication was performed by the verifier
* Create a display and filtering options based where on common domains occur 
in list-post header fields and DKIM signatures (recommended in section 5.7) 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html