[ietf-dkim] brand protection, was Is anyone using ADSP?
iane at sussex.ac.uk
Mon Oct 19 03:59:30 PDT 2009
>> authentication-results header for the original signature, if that header
>> were signed, and the list domain had a reasonable reputation.
> The problem with rejects is that it can cause a MLS to initiate sending
> subscriber removal notification messages. For example, the mipassoc.org
> list server will send you a "Last Warning" removal notification if your
> hosting server rejected a list message X number of times. That was the
> key issue and reason I posted the concern; we now have concrete proof of
> an interoperability problem caused by the intermediary intentionally
> ignoring RFC 5671 restrictive policies. IOWs, we now have user victims
> who with no fault of their own are now subject to removal threats due to
> MLS signer *neglectfully* not filtering this ADSP domains.
I understand that issue. That's why receivers should NOT reject messages
with broken DKIM records when they come from a trusted mailing list. They
should assess the list, not the original sender. That's sensible, because
list recipients usually know more about the list than they do about all the
people subscribed to the list.
> In regards to the **pass, IMV, I am not concern about how we can accept
> 3rd party signatures. There are ideas for this. But its probably better
> to use another policy and not DKIM=ALL unless the specs were changed to
> provide those semantics. But as it stands, it clearly does not say that
> 3rd party signatures are implied in shape or form. I see no proof or
> wordings whatsoever that DKIM=ALL allows 3rd party signers.
It's there. Section 1 of rfc5617 "The basic requirements for ADSP are
given in [RFC5016]. This
document refers extensively to [RFC4871] and assumes the reader is
familiar with it."
rfc4817 is DKIM, rfc5016 is "Requirements for a DomainKeys Identified Mail
(DKIM) Signing Practices Protocol"
rfc5016 section 3.1 gives a use case that is implemented with the tag
"dkim=all": "Domain Alice provides information that it signs all outgoing
mail, but places no expectation on whether it will arrive with an intact
first party signature. Domain Bob could use this information to bias its
filters to examine the message with some suspicion."
The interpretation is left to the recipient. In my view, if the recipient
sees no good reason that there's no intact first party signature, the mail
could be rejected but not discarded, thus allowing senders to be alerted to
false positives. If the receiver sees a good reason that a signature is
broken, they should accept it. A good reason would be that the message has
been forwarded by a mailing list (DKIM or SPF validated) that the recipient
is subscribed to.
Also, read section 5.3 and note the difference between requirement 3 and
requirement 4. I believe that 3 is implemented with dkim=all and 4. is
implemeted with dkim=discardable.
And, note 4.3: "...remailers that break DKIM first party
signatures can be potentially assessed by the receiver based on the
receiver's opinion of the signing domains that actually survived."
> The fact that
> it is open-ended with no explicit action semantics does not mean 3rd
> party signatures are allowed. If that is the desire then IMV it needs to
> be updated to say so. Otherwise we have what we have now - confusing.
> With all due respect to Mr. Deutschmann, Mr. Levine wrote RFC 5617. Not
> Mr. Thomas. Mr. Levine's interpretation is what counts.
And, Mr Levine appears to agree with Mr Thomas, but be concerned about
misinterpretations. I agree that the implementation guide needs to be very
explicit about this scenario, and it might even be useful for the ADSP RFC
to be updated to provide guidance here.
IT Services, University of Sussex
For new support requests, see http://www.sussex.ac.uk/its/help/
More information about the ietf-dkim