[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John L
That's the problem: if you do that, domains like Cisco --
or anybody
else who uses mailing lists -- will *never* publish a "we sign
everything" policy even though we do.
And that's a problem because ... ? There are all sorts of
true statements that you can make about your outgoing mail,
almost none of which are of any use to anyone else. This
appears to be one of them.
0: "mail from this domain may transit manglers, adjust accordingly"
That's not a bit, that's a fact of life. None of us have any
idea what paths our mail might take on its way through the
mail morass.
I agree with John here. Every email message can be mangled.
However senders can control mangling on their outbound path and receivers can
control mangling on their inbound path. The only case when meesages get mangled
that is beyond the control of deployments is mailing lists.
It may make sense for Cisco to state 'lots of our mail goes through mailing
lists, be advised' but the care value stuff is confused in my view.
If a policy of that type is going to have any utility at all it would be
restricted to specific signers, possibly to specific signatures.
Now I don't suggest we do this at this point but consider the following:
Policy is:
ALWAYS-PRESENT REPORT(EESP, EESP.cisco.com)
That is signature is always present, if you see an error report it via a yet
to be developed protocol EESP.
Two key records are used to sign messages:
Record1: Is used for mail that is expected to go through successfully
Record2: Has a 'loose' flag on it to warn that this mail may well fail.
The decision to use record 1 or record 2 is made by the signer on the basis of
the feedback from the EESP system. That should identify the mailing lists that
mangle mail in a reasonably short time provided that there is at least one
person on the list who supports EESP reporting.
The point is that the idea of applying any numeric description to the mail from
a domain like Cisco.com strikes me as far to general to have operational value.
The reactive scheme I describe is capable of tracking differences.
The key records are part of the policy system. If you want to give the verifier
information on how to react to a failed signature this should be done in the
most specific context that is available, in this case the key record for which
the signature failed.
It is arguable that the reporting function for failed signatures should
likewise apply to the key record rather than the generic policy record.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html