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