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
