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.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html