[exim-dev] [Bug 2179] Default dkim_sign_headers should be ch…

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 2179] Default dkim_sign_headers should be changed or documented
https://bugs.exim.org/show_bug.cgi?id=2179

Ian Kelling <iank@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---


--- Comment #2 from Ian Kelling <iank@???> ---
> RFC4871
>
> 5.5.   Recommended Signature Content
> [...]
> The following header fields SHOULD be included in the signature, if
>    they are present in the message being signed:

>
>    o  From (REQUIRED in all signatures)
>    o  Sender, Reply-To
>    o  Subject
>    o  Date, Message-ID
>    o  To, Cc
>    o  MIME-Version
>    o  Content-Type, Content-Transfer-Encoding, Content-ID, Content-
>       Description
>    o  Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc,
>       Resent-Message-ID
>    o  In-Reply-To, References
>    o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
>       List-Owner, List-Archive

>
> 5.4.   Determine the Header Fields to Sign
> [...]
>    Signers MAY claim to have signed header fields that do not exist
>    (that is, signers MAY include the header field name in the "h=" tag
>    even if that header field does not exist in the message).  When
>    computing the signature, the non-existing header field MUST be
>    treated as the null string (including the header field name, header
>    field value, all punctuation, and the trailing CRLF).

>
>       INFORMATIVE RATIONALE: This allows signers to explicitly assert
>       the absence of a header field; if that header field is added later
>       the signature will fail.


Yes, this further proves my point about the documentation being wrong.
"MAY" is not at all a synonym with "recommended." So the documentation
claims to include "recommended" but in actually includes "recommended" +
"may". Both terms are defined in https://www.ietf.org/rfc/rfc2119.txt

--
You are receiving this mail because:
You are on the CC list for the bug.