Ian Eiloart wrote:
--On 16 October 2009 10:28:01 -0400 hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
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