I tried sending this on June 4th (a short while before I was actually
subscribed to the list), but it never seems to have made it. Trying again
...
------- Forwarded message -------
From: "Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>
To: mail-vet-discuss(_at_)mipassoc(_dot_)org
Subject: Re: New draft for review
Date: Mon, 04 Jun 2007 15:53:54 +0100
Individual submission M. Kucherawy
Internet-Draft Sendmail, Inc.
Intended status: Standards Track May 19, 2007
Expires: November 20, 2007
Message Header for Indicating Sender Authentication Status
draft-kucherawy-sender-auth-header-05
This draft doesn't seem to cover the case of dkim-signatures that I
expected it to cover.
I am concerned about the case of a message that, during its meanderings
though various initial submissions, forwardings, mail-list expansions, etc
has picked up several signatures (remember that Dkim-Signature is also a
Trace field), and may have been verified by various parties en route.
So, suppose it arrives at a mailing-list expander who checks its signature
and wishes to record the fact (maybe because he is about to add some
boilerplate to the message body that will invalidate the existing
signature for subsequent recipients).
So he would add:
Authentication-Results: list-expander.example.com
header.dkim-signature=sending.domain; dkim=pass (good signature)
Received: by list-expander.example.com ...........
Dkim-Signature: ........... d=sending.domain; ..........
Note that he does not assert that the From or Sender fields had been
validated (though he could do that as well if he wished). He simply
asserts that he checked the signature provided by sending.domain against
the message header fields and body, and that it passed (some later
recipient can worry about whether signatures from sending.domain are
useful and meaningful, or not).
Now, he adds his boilerplate to the body (thereby invalidating the
existing signature) and resigns it himself, including his own
Authentication-Results header in the signature:
Dkim-Signature: ...... d=list-expander.example.com;
h=...:Dkim-Signature:...; ...
Authentication-Results: list-expander.example.com
header.dkim-signature=sending.domain; dkim=pass (good signature)
Received: by list-expander.example.com ...........
Dkim-Signature: ........... d=sending.domain ..........
Now, subsequent recipients (or the MTAs at their boundaries) can check the
new signature, decide whether to believe it and, if so, apply their
policies to the original signature by sending.domain as if that signature
has been validated.
BUT, header.dkim-signature=... is not allowed by the proposed draft and
this needs to be rectified. Also, the usual problems of identifying which
of the various Dkim-Signatures is referenced by which of the various
Authentication-Results and other Dkim-Signatures arises. RFC 4817 deals
with this, but not in an entirely satisfactory manner (it assumes that
header order has been faithfully preserved).
--
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