I have a problem with dropping mention of the originator headers. I can
live with them moving to SHOULD be signed in place of MUST be signed.
Tony
Jim Fenton wrote:
> Eric Allman wrote:
>> I've heard some discussion the last couple of days that we should drop
>> the MUST for signing originator headers and Resent-* blocks, since
>> this isn't an interoperability issue (but is perhaps a usefulness
>> issue). This is, in some sense, dictating policy instead of being
>> confined to mechanism, which we've been assiduously avoiding. Viewed
>> that way, it seems inappropriate to have this requirement.
>>
>> Of course, a verifier would be completely within reason to ignore
>> signatures that didn't sign the From header, but that's up to them.
>>
>> If we can get a very quick consensus I can get this into base-04
>> (which is going to be submitted today come hell or high water --- oh
>> wait, that was Dallas). It seems consistent with the other changes
>> we've been making, which is why I have some small hope we can get this
>> through in just a couple of hours.
>>
>> Thoughts?
>
> If we do this, there needs to be some strongly-worded but non-normative
> guidance that reminds people that if they want their signature to be
> useful, there are some header fields they really ought to sign,
> including From, Subject, Date, and probably Sender (the latter on
> account of Outlook clients). Otherwise, the signature really doesn't
> mean much, and if the verifier does something like remove unsigned
> header fields, the recipient is going to see a lot of blanks.
>
> In other words, it doesn't need to be a normative MUST because not
> signing From doesn't break the protocol. Whether it's a normative
> SHOULD, a should (note lower case) or a non-normative note I'm not sure.
>
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
