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

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