ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Associated Signatures

2008-01-25 09:01:21
On Thu, 24 Jan 2008 20:01:54 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:

On Jan 24, 2008, at 4:36 AM, Charles Lindsey wrote:

On Wed, 23 Jan 2008 19:44:47 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:

OK, an address in one of those headers matches the signature iff the various d=, i= and g= tags so determine according to RFC 4871, taking the local-part of the address into account if necessary.

I do not agree with a local-part exclusion.

I never proposed a local-part exclusion.

DKIM-Signature: i=admin(_at_)example(_dot_)com d=example.com ... (no g= parameter in key)
Sender: Tom Smith <admin(_at_)example(_dot_)com>
From: Will Jones <W(_dot_)Jones(_at_)eng(_dot_)example(_dot_)com>

This signature indicates the message is compliant with example.com's signing policy. There should be no reason for a recipient to check example.com's SSP record. If they did and it indicated an assertion of "all" or "strict", this message should be considered complaint.

Inspection of this signature also indicates which entity introduced the message. Matching this identity with the header might lead recipient's to conclude Tom Smith introduced the message as a Sender on behalf of Will Jones <W(_dot_)Jones(_at_)eng(_dot_)example(_dot_)com>, but this header MUST be included within the signature's hash before reaching that conclusion.

When highlighting whether a message is signed, and by whom, this highlighting should be limited to information included within the signature's hash. The signature's coverage with respect to From header compliance should also consider the g= and t= parameter when signing for other identities not within the From header.

All that is perfectly correct. I never said or proposed otherwise.

You wish to include SSP discovery for any header, rather than just for those within the From header lacking a signature within a domain at or above the email-address domain?

Yes, it should apply to any header which ought not to have escaped outside the signers boundary without being signed, according to his published SSP. Our SSP draft would specify exactly which those headers were (and maybe there would be more tags in the SSP records than we have proposed so far).

I do not agree. It seems reasonable to limit SSP compliance to only the From email-addresses. However, unrestricted signatures for other headers must also be considered proof of policy compliance. SSP definitions must reflect the concept that a signature _defines_ the signer's policy.

If the sender wishes to specify in his SSP that he signs Sender, Resent-*, etc headers if they purport to include his domain, then he should be able to do so.

Whether that is implied automatically by 'strict', or by some yet-to-be-invented other tag is just a small technical detail to be decided.

NO IT DOESN'T, because we all agree that these cases of multiple different addresses in the headers mentioned are going to be exceedingly rare. In 99.99% of cases there will be just one From address, the Sender (if present) will be from the same domain, and there will be no Resent-* headers at all.

This might depend upon the level of email being handled. Expecting a process to discover SSP records for an unlimited number of domains is not safe for the receiver or potential targets of the transactions. The resulting overhead is more than able to result in a denial of service.

Nobody is suggesting an "unlimited number of domains". But it needs to be large enough for normal expected usage. I have suggested 50. You have mentioned 10, which is a bot low for my taste.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html