Ian Eiloart wrote: > > --On 16 October 2009 10:28:01 -0400 hector <[email protected]> > wrote: > > I'd reduce it to this: > ADSP RECORD > +=============================================+ > | | UNKNOWN | ALL | DISCARDABLE | > |=============================================| > D | NONE | pass | reject* | discard | > K |-------+-----------+----------+--------------| > I | 1PS | pass | pass | pass | > M |-------+-----------+----------+--------------| > | 3PS | pass | pass** | discard | > +=============================================+ > > * reject rather than discard, so that the sender has a chance of detecting > their error. Especially true if you have an spf pass, for example, and the > domain has a reasonable reputation score. > > ** pass, provided the third party signature passes, and you have some > explanation for the breakage - eg, the message has been through the list. > However, in this situation, you must rely on the reputation score for the > third party signing domain, not the original signing domain or the author. > This is a case where I'd (very slightly) prefer to see a broken signature, > than none at all, I think. I might even give credence to an > 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. 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. 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. -- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
