ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Mailing lists as 2822-Sender

2007-12-03 11:49:59

On Dec 3, 2007, at 8:58 AM, Dave Crocker wrote:

Bill,

Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
A mailing list is an original mail object that is comprised of vetted submitted material much like a newspaper. It should take submitted material, empty the accompanied envelope and remail using a fresh clean envelope with new headers.

In the abstract, the model you describe is probably the best to use. I think it is obviously true for a "digest" mode of mailing out a collection of postings.

For the case that we are all most used to, it is probably still true, but less obviously, since recipients perceive the message as "from" the original author.

That difference between actual responsibility, versus reader- perceived responsibility, is the issue.


When SSP makes a STRICT assertion, then From email-addresses not signed by the same or parent domain are suspicious (and likely rejected). The STRICT assertion is incompatible with the use of mailing-lists. It is more likely that for a mailing-list the Sender, and not the From, last modified (flattened) message content. With a mailing list, it is also unlikely that the identity represented by the From email-address had been authenticated.

Even when SSP makes a STRICT assertion, there is no assurance the identity represented by the From email-address will have been authenticated. Making a STRICT SSP assertions may necessitate the DKIM signature to lie or remain ambiguous as to who's behalf the message had been signed. Remaining ambiguous may be necessary simply because there is _no_ means to achieve STRICT policy compliance for other headers. The STRICT SSP assertion intentionally breaks many normal use scenarios, and in doing so, places restrictions on the use of the i= semantics.

Should DKIM reinforcing a perception that From field email-addresses _always_ represents the responsible identity for message content? DKIM is limited to the domain, and of course the domain _never_ creates message content. A STRICT SSP policy is domain-wide and _breaks_ email. Tactics to overcome this breakage, along with the dubious recognition of email-addresses creates more opportunities to mislead recipients. Repair tactics using visible sub-domains email- addresses having different policies will increase recipient confusion. As internationalization becomes prevalent, identities represented by email-addresses will become even more ambiguous.

Having said that, TPA-SSP can minimize breakage while also eliminate some of the i= semantic restrictions. TPA-SSP also improves the ability to obtain a higher granularity than just the domain, as well as establish FULL "strict" compliance based upon Sender in addition to just From headers. This is done by allowing policy compliance to include more than just the From header, and by allowing transparent use of signing sub-domains (which is considered a third-party domain). Messages signed with authorized sub-domains can express different policies and scope without recipients ever seeing this complexity. TPA-SSP follows KISS from the recipient's perspective. The complexity of TPA-SSP is well hidden and does not increase overhead beyond that needed to implement a CNAME. : )

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