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