ietf-dkim
[Top] [All Lists]

[ietf-dkim] List Server ADSP Support

2009-10-13 19:51:35
Ian Eiloart wrote:


So what you are saying is that LIST SERVER developers SHOULD NOT add
ADSP features to restrict signing of ADSP domain nor bother to see if
it should allow these restrictive domains to subscribe?

They should add features. But "DISCARDABLE" ('discard' isn't a value, and 
'discardable' doesn't mean 'discard'), should not be treated the same as 
"ALL". It's reasonable for a list to rejected mail that it is about to 
render discardable, but there's no reason to reject mail with "ALL".


IMO, as a software developer, it is programmatically inconsistent to 
create an potential problem for list distribution when the downlinks 
can results in negative results.  As it was outlined in the archives, 
discussed and proposed in the DSAP  draft:

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12

specifically outlining the MLS concerns and considerations, I can not 
in good conscious claim or work with the idea of RFC 5617 ignorance 
knowing full well there exist an IETF standard that receivers can use 
to cause MLS problems.

Remember RFC5617 says " 3.2 ... o  If a message has a Valid Signature other 
than an Author Domain Signature, the receiver can use both the Signature 

and the ADSP result in its evaluation of the message."

What is most important to receivers is what section 3.2 items 3 says:

    o  All messages from this domain are signed with an Author
       Domain Signature and are discardable, i.e., if a message
       arrives without a valid Author Domain Signature, the
       domain encourages the recipient(s) to discard it.

coupled with section 4.2.1 with direct semantics for exclusive 1st 
only signature semantics.

Coupled with the deployment guide sections 6.1, 7.3.1

    http://tools.ietf.org/html/draft-ietf-dkim-deployment-08

Coupled with the Threat Analysis RFC 4686 summary recommendation:

   DKIM is effective against the use of specific identities only
   when there is an expectation that such messages will, in fact,
   be signed. The primary means for establishing this is the use
   of Sender Signing Practices (SSP), which will be specified by
   the IETF DKIM Working Group.

All in all, allows for a wide interpretation and implementation for 
POLICY to be a natural part of the DKIM total solution.

This issue on the table is whether resigners, a direct threat to DKIM 
mail integrity, are obligated to play by the same rules and follow all 
the semantics, provisions and recommendations peppered throughout the 
documents.

Thanks

-- 
HLS

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