Charles Lindsey wrote:
On Tue, 13 Oct 2009 02:24:56 +0100, hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
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