Charles Lindsey wrote: > On Tue, 13 Oct 2009 02:24:56 +0100, hector <[email protected]> > wrote: > >> The deployment guide section 6.5 writes: >> >> Any forwarder that modifies messages in ways that will break >> preexisting DKIM signatures SHOULD always sign its forwarded >> messages. > > But it should in addition say that it SHOULD also add an > Authentication-Results header for the signature it is about to break AND > include that A-R header within what it then signs. That will provide much > more information to the ultimate recipient.
But what is its not there? DKIM=DISCARDABLE provides a Domain Policy that mail must be signed and valid. Even if it was there, the transaction could be a 3rd party DSAP violation >> Before any forwarder attempts to modifies messages and add >> a new signature to the message, it SHOULD look at the >> ADSP record for the 5322.From domain. If the domain has >> an ADSP record with "dkim=all" or "dkim=discardable", the >> forwards SHOULD NOT forward the message. > > No, I think that would lose too much genuinely wanted mail. and 1) create a loophole for spoofs, 2) create interoperability issues with downlinks, 3) create false subscriber removal notifications. Did we forget the Threat Analysis RFC 4886? http://tools.ietf.org/html/rfc4686#page-10 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. Keep in mind that the original SSP included policies that specifically dealt with 3rd party signatures inclusion and exclusion: - All mail from the entity is signed; unsigned email MUST NOT be accepted, but email signed by a third party SHOULD be accepted. ! All mail from the entity is signed; third-party signatures SHOULD NOT be accepted By ADSP effectively removing the op=- SSP policy, we lost mailing list approval controls. -- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
