[ietf-dkim] chained signatures, was l= summary
chl at clerew.man.ac.uk
Fri Jun 5 06:36:09 PDT 2009
On Thu, 04 Jun 2009 20:19:34 +0100, Douglas Otis <dotis at mail-abuse.org>
> On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
>> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
>>> You're not required to sign them, but it's not a bad idea.
>> Then why are people on this list not trying to enocourage that good
>> practice? Indeed, why are they so vociferously trying to DIScourage
> Before A-R headers can be trusted, A-R headers MUST be removed by
> incoming border MTAs. See section 1.6 of RFC 5451.
No, that is NOT what section 1.6 of RFC 5451 says. It requires removal of
any pre-existing A-R header "claiming to be valid with in its [the ADMD's]
boundaries", which essentially means (AIUI) any A-R header that might be
mistaken for one that might/would/should have been created within that
BUT the cases we are considering are where, in the course of its travels,
a message has picked up two signatures, S_1 and S_2, but where S_1 has
(possibly) been invalidated by some change at an intermediate site
(typically a mailing list expander) en route, and even where S_1 has been
removed at some point. So there are at least three ADMDs involved:
| sending ADMD | Mail List ADMD | Receiving
| orig MUA orig MTA | | Recv MTA Recv
| M ---> M+S_1 --+-> M+S_1+A_1 -> M*+A_1+S_2 --+-> M*+A_1+S_2+A_2
A_1 was added by a validator/assessor on the strength of S_!
A_2 was added by a validator/assessor on the strength of S_2
Observe that M was transmogrified into M* at some point, breaking S_!.
If some "helpful" MTA, somewhere between the Mail List and Receiving
ADMDs, had also added an A_2, then THAT is the one that should be removed
by Recv MTA, before inserting its own (which it obviously would not do if
S_2 covered A_1, and A_1 was no longer there).
What Recv MTA passes on to Recv MUA is entirely a matter to be decided
within the Receiving ADMD, but I hope it would be everything that was
available (even S_1 if it were still available).
Note that Appendix B.6 of RFC 5451 contains an example exactly equivalent
to the one I have just given, including the retention of A_1 (and even
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Email: chl at clerew.man.ac.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
More information about the ietf-dkim