Mailing List Archive

[Bug 2706] DKIM and Received headers
https://bugs.exim.org/show_bug.cgi?id=2706

Eugene Berdnikov <bd4@protva.ru> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|medium |low

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2706] DKIM and Received headers [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2706

--- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
Possibly those other MTAs are running a validation check on a message *after*
they have added their own Received: header to it? I can't think of a reason
that Exim might be treating Received: specially on the signing side.

I should point out that RFC 6376, in "5.4.1. Recommended Signature Content"
recommends agains signing Received. That doesn't mean there isn't a bug,
either here or in the comparisons you made.

You may be able to see the headers being selectied for signing using Exim's
debug facilities.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2706] DKIM and Received headers [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2706

--- Comment #2 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
I've just tested Exim 4.90 with "+Received", "=Received" and "Received" and it
behaves as expected when checking with Mail::DKIM::Verifier (and amending
headers to fit the signature).

The first two are over-signing the Received: header so it is inevitable that
the signature will fail to validate after another one is added.

Exim does DKIM validation at SMTP time while reading the incoming message so it
doesn't have an additional Received: header yet. With "+Received", SpamAssassin
will fail validation because this happens after another Received: header is
added.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2706] DKIM and Received headers [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2706

Jasen Betts <jasen@treshna.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jasen@treshna.com

--- Comment #3 from Jasen Betts <jasen@treshna.com> ---
DKIM-Sgnature and Received are both trace headers, so it should be unambiguous
which headers are signed and which are not even after intermediate systems have
added further headers.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2706] DKIM and Received headers [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2706

--- Comment #4 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
DKIM-Signature: is not a trace header field according to RFC6376 5.4

Signers may sign non-existent headers to prevent additional headers being
added.

Both the signer and verifier are working correctly. If you over-sign the
Received: header then no more can be added without invalidating the signature.

If you want to interpret the Received: headers to imply the state of the
message at each hop then you can do that prior to verification but it is not
part of the standard.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2706] DKIM and Received headers [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2706

--- Comment #5 from Eugene Berdnikov <bd4@protva.ru> ---
(In reply to Simon Arlott from comment #2)
> I've just tested Exim 4.90 with "+Received", "=Received" and "Received" and
> it behaves as expected when checking with Mail::DKIM::Verifier (and amending
> headers to fit the signature).

Simon, thank you for reference to Mail::DKIM::Verifier, it saves time.

> Exim does DKIM validation at SMTP time while reading the incoming message so
> it doesn't have an additional Received: header yet. With "+Received",
> SpamAssassin will fail validation because this happens after another
> Received: header is added.

Yes, this a point I did not understand until reread RFC6378 carefully.

> The first two are over-signing the Received: header so it is inevitable that
> the signature will fail to validate after another one is added.

Not two. Only "+Received" form do oversigning.
The "=Received" instructs to sign all existing headers and nothing more.
The "Received" instruct to sign a single (lowermost) header.

However, I really do not like how it is documented (in Ch.58 par.2:
"A name can be prefixed with either an “=” or a “+” character.
If an “=” prefix is used, all headers that are present with this name
will be signed. If a “+” prefix if used, all headers that are present
with this name will be signed, and one signature added for a missing
header with the name will be appended.")

I propose this variant:

A name can be prefixed with either an “=” or a “+” character, instructing
Exim how many instances of the named header should be included in signature.
If name is not prefixed, only a single (lowermost) header field is signed.
If name is prefixed by "=", all existing headers are signed, from bottom
to top, and each occurance is referenced in "h=" tag of DKIM-Signature
(see RFC6376 sect 5.4 for details). If name is prefixed by "+", all
existing headers are signed like with "=" prefix, plus additional null
header instance is included into signature (and displayed in "h=" tag),
preventing from joining additional headers with this name to the message.

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