RE: [ietf-dkim] A more fundamental SSP axiom

["Hallam-Baker, Phillip" <[e-mail]>]

> [mailto:[e-mail]] 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