On 19/Oct/11 01:20, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>> 
>>   DKIM-Canonicalized-Body: relaxed:
>>     BLAHBLAH....
>>   DKIM-Canonicalized-Body: simple:
>>     blahblah....
>> 
>> Tag l= doesn't play, unless we want to report hashes too.
> 
> That's not true; if "l=" is there in one signature and not in
> another, then those two will produce different canonicalized
> bodies, even if they use the same canonicalization.

Not formally.  Section 3.4 of RFC 6376 specifies canonicalization with
no mention of l=.  OTOH, Section 3.7 says

 In hash step 1, the Signer/Verifier MUST hash the message body,
 canonicalized using the body canonicalization algorithm specified in
 the "c=" tag and /then/ truncated to the length specified in the "l="
 tag.  [emphasis added]

Does the definition of DKIM-Canonicalized-Body in Section 3.2.3 have
to specify that "the canonicalized body MAY be truncated to a length
greater or equal to the value of (the highest) l="?

>> [Authser-id]'s only use, AFAICS, is to relate the A-R in the second
>> part with one or more A-Rs in the reported message, which may be not
>> obvious in some edge cases.
> 
> Actually in the context of the report, I would trust the report's
> A-R and none of the quoted ones.  I know for certain where it
> originated.  And in that sense, the "authserv-id" doesn't really
> matter here.

I agree that it is sound to have the results of apposite checks in the
report's A-R.  That really depends on how the report's A-R is going to
be specified.  One possibility is to implement a meaning of "here's
why I'm sending this report".  Such semantics would exclude, for
example, spf=pass if the reported failure is a broken signature.
Indeed, that's not relevant for debugging, and for generic policy
tracking it might be as good to know as, say, Received: fields.

In any case, the contents of the report's A-R ought to be specified
and exemplified in the I-D, IMHO.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf

Reply via email to