Mailing List Archive

On 22/10/2023 19:48, Ian Z via Exim-users wrote:
> dkim-signing with the full set of
> headers as per the exim default set above is broken

I'll take issue with "broken".

If (and there's the question) you think that a DKIM signature should
detect when a message has been modified, do you not think that
adding headers is a modification?
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 22/10/2023 20:04, Jeremy Harris via Exim-users wrote:
> On 22/10/2023 19:48, Ian Z via Exim-users wrote:
>> dkim-signing with the full set of
>> headers as per the exim default set above is broken
>
> I'll take issue with "broken".
>
> If (and there's the question) you think that a DKIM signature should
> detect when a message has been modified, do you not think that
> adding headers is a modification?

Definitely not broken, just a trap for the unwary... I ran into the same
problem on the PostgreSQL lists with my personal server. Altering the
list of headers included in the signature fixed the problem.

Ray.


--
Raymond O'Donnell // Galway // Ireland
ray@rodonnell.ie


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sun, Oct 22, 2023 at 08:51:37PM +0100, Ray O'Donnell via Exim-users wrote:

> On 22/10/2023 20:04, Jeremy Harris via Exim-users wrote:

> > > dkim-signing with the full set of headers as per the exim
> > > default set above is broken

> > I'll take issue with "broken".

> > If (and there's the question) you think that a DKIM signature
> > should detect when a message has been modified, do you not think
> > that adding headers is a modification?

> Definitely not broken, just a trap for the unwary... I ran into the
> same problem on the PostgreSQL lists with my personal
> server. Altering the list of headers included in the signature fixed
> the problem.

To be clear, I'm not blaming exim. It is a matter best left to
configuration by each site admin. I'm just saying that because it is
such a trap (thanks for the word, Ray), it's a good candidate to be
written up somewhere.

I wonder what the fabulous debian configuration daoes in this respect.

--
Ian

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-22 Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
[...]
> If (and there's the question) you think that a DKIM signature should
> detect when a message has been modified, do you not think that
> adding headers is a modification?

Hello,

I think it depends on which the header would be added. Some additions
should be allowed. Exim's default setting for dkim_sign_headers is
extremely conservative and imho does not make sense. I had tried to
discuss this in https://bugs.exim.org/show_bug.cgi?id=2394.

I personally am using +From:+Sender:+Reply-To:+Subject:+Date:+Message-ID:+To:+Cc:+MIME-Version:+Content-Type:+Content-Transfer-Encoding:+Content-ID:+Content-Description:=Resent-Date:=Resent-From:=Resent-Sender:=Resent-To:=Resent-Cc:=Resent-Message-ID:+In-Reply-To:+References:=List-Id:=List-Help:=List-Post
I am sure this set is not perfect and I have missed something, though.

cu Andreas

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-23 Ian Z via Exim-users <exim-users@lists.exim.org> wrote:
[...]
> I wonder what the fabulous debian configuration daoes in this respect.

We have a open bug about it
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939808 but have not
yet overridden exim's default.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 23/10/2023 06:37, Andreas Metzler via Exim-users wrote:
> Exim's default setting for dkim_sign_headers is
> extremely conservative and imho does not make sense.

It's also as per RFC 6376 Section 5.4.1. "Recommended Signature Content"
(at least wrt. the List- headers; I didn't check them all).
So Exim takes the opinion of the working group that defined DKIM, here.

But it's an option on the transport, so any set you like can
be used. There are also a couple of macros so you can take
either default set or an oversigned equivalent and edit it
using a string-expansion.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-23 Jeremy Harris via Exim-users <exim-users@lists.exim.org> wrote:
> On 23/10/2023 06:37, Andreas Metzler via Exim-users wrote:
> > Exim's default setting for dkim_sign_headers is
> > extremely conservative and imho does not make sense.

> It's also as per RFC 6376 Section 5.4.1. "Recommended Signature Content"
> (at least wrt. the List- headers; I didn't check them all).
> So Exim takes the opinion of the working group that defined DKIM, here.
[...]

Kind of. The RFC has big fat disclaimer that it only provides very rough
guidance ("The choice of which header fields to sign is non-obvious.")
and is very very thin on details, afaict it does not say a thing about
oversigning. Exim could claim to follow the RFC no matter whether it had
List-Id, =List-Id or +List-Id in its defaults. So exim needs to make
a deliberate choice even if it "follows" the RFC. The one chosen is not
a good one imho.

cu Andreas


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi!

I'm also looking into optimizing my DKIM configuration, especially which
headers to sign. Unfortunately, DMARC reports tell you only that the DKIM
verification failed but not why. The default for dkim_sign_headers doesn't
work well for me.

On Mon, 23 Oct 2023, Andreas Metzler via Exim-users wrote:

> I think it depends on which the header would be added. Some additions
> should be allowed. Exim's default setting for dkim_sign_headers is
> extremely conservative and imho does not make sense. I had tried to
> discuss this in https://bugs.exim.org/show_bug.cgi?id=2394.
>
> I personally am using +From:+Sender:+Reply-To:+Subject:+Date:+Message-ID:+To:+Cc:+MIME-Version:+Content-Type:+Content-Transfer-Encoding:+Content-ID:+Content-Description:=Resent-Date:=Resent-From:=Resent-Sender:=Resent-To:=Resent-Cc:=Resent-Message-ID:+In-Reply-To:+References:=List-Id:=List-Help:=List-Post
> I am sure this set is not perfect and I have missed something, though.

There some changes between the RFCs:

RFC4871, Section 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


RFC6376, Section 5.4.1, Recommended Signature Content

o From (REQUIRED; see Section 5.4)
o Reply-To
o Subject
o Date
o To, Cc
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o In-Reply-To, References
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive

Wouldn't it make sense to update the default for dkim_sign_headers
accordingly? Anyway, I'll try RFC6376's recommended headers and hope it
will decrease my DKIM verification issues.

ciao
Markus
--
/ Markus Reschke \
\ madires@theca-tabellaria.de /


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, 23 Oct 2023, Markus Reschke via Exim-users wrote:

> I'm also looking into optimizing my DKIM configuration, especially which
> headers to sign. Unfortunately, DMARC reports tell you only that the DKIM
> verification failed but not why. The default for dkim_sign_headers doesn't
> work well for me.
>
> On Mon, 23 Oct 2023, Andreas Metzler via Exim-users wrote:
>
>> I think it depends on which the header would be added. Some additions
>> should be allowed. Exim's default setting for dkim_sign_headers is
>> extremely conservative and imho does not make sense. I had tried to
>> discuss this in https://bugs.exim.org/show_bug.cgi?id=2394.
>>
>> I personally am using
>> +From:+Sender:+Reply-To:+Subject:+Date:+Message-ID:+To:+Cc:+MIME-Version:+Content-Type:+Content-Transfer-Encoding:+Content-ID:+Content-Description:=Resent-Date:=Resent-From:=Resent-Sender:=Resent-To:=Resent-Cc:=Resent-Message-ID:+In-Reply-To:+References:=List-Id:=List-Help:=List-Post
>> I am sure this set is not perfect and I have missed something, though.
>
> There some changes between the RFCs:
>
> RFC4871, Section 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
>
>
> RFC6376, Section 5.4.1, Recommended Signature Content
>
> o From (REQUIRED; see Section 5.4)
> o Reply-To
> o Subject
> o Date
> o To, Cc
> o Resent-Date, Resent-From, Resent-To, Resent-Cc
> o In-Reply-To, References
> o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
> List-Owner, List-Archive
>
> Wouldn't it make sense to update the default for dkim_sign_headers
> accordingly? Anyway, I'll try RFC6376's recommended headers and hope it will
> decrease my DKIM verification issues.

I think one of the issues (the one IanZ reported) is that RFC4871
says that
The following header fields SHOULD be included in the signature,
*** if they are present in the message being signed: ***
but Exim signs the List-* headers even if the do not exist.
RFC6376 drops those words, which could be taken to mean that Exim is
currently correct. However signing those headers that are not present
ensures that messages that go through many mailing lists fail that
signature check.

I believe that the default for dkim_sign_headers should have '=' at least for each of the List-* headers,
as Andreas has done.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi!

On Mon, 23 Oct 2023, Andrew C Aitchison via Exim-users wrote:

> I believe that the default for dkim_sign_headers should have '=' at least for
> each of the List-* headers,
> as Andreas has done.

Yes, that would be reasonable.

BTW, RFC6376 comes with inconsistencies about the headers to sign. In
section 5.4. 'Determine the Header Fields to Sign' it notes:

INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A
third strategy is to sign only "well-known" headers. Note that
Verifiers may treat unsigned header fields with extreme
skepticism, including refusing to display them to the end user or
even ignoring the signature if it does not cover certain header
fields. For this reason, signing fields present in the message
such as Date, Subject, Reply-To, Sender, and all MIME header
fields are highly advised.

But in 5.4.1. it neither lists 'Sender' nor any MIME related headers. And
the note above indicates to sign present headers. A lot of leeway on how
to interpret the RFC.

ciao
Markus
--
/ Markus Reschke \
\ madires@theca-tabellaria.de /


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, Oct 23, 2023 at 11:51:21AM +0200, Andreas Metzler via Exim-users wrote:

> > It's also as per RFC 6376 Section 5.4.1. "Recommended Signature
> > Content" (at least wrt. the List- headers; I didn't check them
> > all). So Exim takes the opinion of the working group that defined
> > DKIM, here.

> Kind of. The RFC has big fat disclaimer that it only provides very
> rough guidance ("The choice of which header fields to sign is
> non-obvious.") and is very very thin on details, afaict it does not
> say a thing about oversigning.

Right, in the sub-section cites it says (lightly paraphrased):

The following headers SHOULD be signed *if they are present* in the
message.

Emph mine. So, like Andreas writes, if they are *not* present, this is
vacuous.

--
Ian

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi!

On Mon, 23 Oct 2023, Ian Z via Exim-users wrote:

> On Mon, Oct 23, 2023 at 11:51:21AM +0200, Andreas Metzler via Exim-users wrote:

>> Kind of. The RFC has big fat disclaimer that it only provides very
>> rough guidance ("The choice of which header fields to sign is
>> non-obvious.") and is very very thin on details, afaict it does not
>> say a thing about oversigning.
>
> Right, in the sub-section cites it says (lightly paraphrased):
>
> The following headers SHOULD be signed *if they are present* in the
> message.
>
> Emph mine. So, like Andreas writes, if they are *not* present, this is
> vacuous.

When you check out the h tag of the DKIM signature header of the large
email services you'll see that they usually have only a few signed headers
(less processing load) and some oversign specific headers. E.g. gmail
seems to oversign from:to:cc:subject:date:message-id:reply-to, and Yahoo
From:Subject:Reply-To. Based on the DKIM RFCs and the current reality I'd
say that exim's default for dkim_sign_headers is simply overkill and we
should add a bunch of '=' prefixes, maybe a few '+' for essential headers.

ciao
Markus
--
/ Markus Reschke \
\ madires@theca-tabellaria.de /


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, Oct 23, 2023 at 07:23:23PM +0200, Markus Reschke via Exim-users wrote:

> When you check out the h tag of the DKIM signature header of the
> large email services you'll see that they usually have only a few
> signed headers (less processing load) and some oversign specific
> headers. E.g. gmail seems to oversign
> from:to:cc:subject:date:message-id:reply-to, and Yahoo
> From:Subject:Reply-To. Based on the DKIM RFCs and the current
> reality I'd say that exim's default for dkim_sign_headers is simply
> overkill and we should add a bunch of '=' prefixes, maybe a few '+'
> for essential headers.

I have been thinking about this all day, with increasing hopelessness
:-(

Is there even a "best practice" for mailing lists, what they do with
incoming DKIM signatures? I see that this list removes them, and it
really has no choice because it modifies the From header (and maybe
the Subject too, although I won't know about it because I hide it in
my MUA). But the postgres list must keep them, if they were a problem
in my messages.

As it is now, I'm inclined to just stop signing messages to lists.

--
Ian

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sun, 22 Oct 2023, Ian Z via Exim-users wrote:

> On Sun, Oct 22, 2023 at 07:03:19PM +0200, brunoc68 via Exim-users wrote:
>
> > h=Content-Type:Message-ID:Subject:Date:MIME-Version:To:From:Sender:\
> > Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:\
> > Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:\
> > Resent-Message-ID:In-Reply-To:References:\
>
> vvv
> > List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:\
> > List-Archive
> ^^^
>
> I have just been alerted by a fellow subscriber to the
> postgresql-general mailing list that dkim-signing with the full set of
> headers as per the exim default set above is broken: the list server
> appends the list related headers which were absent in my original
> messages, thus making my signature invalid.

I've arrived at this thread also because of posting to the PostgreSQL
mailing list. Here's the actual recommendation I was given:

> This email has a DKIM signature on the List- headers of the email,
> indicating that it is not allowed to pass this email on through a
> mailinglist.
>
> Please ensure that emails you send to the list, and others hosted on the
> same server, allow re-sending on a mailinglist.

So I'm taking a little time to understand DKIM.

To date I have been using exim defaults which is _DKIM_SIGN_HEADERS [0]
on my system is:

From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:\
Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:\
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:\
Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:\
List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive

I see it matches the RFC but is a lot more extensive than I can see in the
"wild" from other mail providers signatures, which seem quite
conservative.

I think the PostgreSQL recommendation seems reasonable, but the doc leaves
me with some questions/ambiguities.

Mainly, that I'm having trouble parsing the documentation's explanation of
dkim_sign_headers entries [0]. I can see 4 cases:

* no prefix: sign the first instance of the named header or absence of it?

* = prefix: sign all instances of the named header, only if present?

* + prefix: sign all instances of the name header or the absence of it?

* repeated header name: sign up to n instances or the absence of it?

Therefore, if following the RFC (which suggests headers "should" be signed
"if they are present" [1]) there should be a lot more use of '=' in the
default? Especially "Resent-*" fields which the default effectively kills
the use of.

The modification to List-Id also leaves me wondering about "Sender". I was
previously under the impression mailing lists used/modified this, but
apparently not.

So I'm experimenting with:

dkim_sign_headers = From:\
=Sender:\
To:\
Cc:\
Reply-To:\
Subject:\
Date:\
Message-ID:\
In-Reply-To:\
References:\
MIME-Version:\
Content-Type:\
Content-Transfer-Encoding:\
Content-ID:\
Content-Description:\
=Resent-Date:\
=Resent-From:\
=Resent-To:\
=Resent-Cc:\
=Resent-Message-ID:\
=List-Id:\
=List-Help:\
=List-Unsubscribe:\
=List-Subscribe:\
=List-Post:\
=List-Owner:\
=List-Archive

Finally (and more theoretical problem than practical...) I'm not clear of
the value of the DKIM signature if it's the message itself that defines
the extent of what is signed (not some DNS record for example)

Thanks

[0] https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_srs_and_dmarc.html
[1] https://www.rfc-editor.org/rfc/rfc4871

--
Mark

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

> I think the PostgreSQL recommendation seems reasonable, but the doc leaves
> me with some questions/ambiguities.
>
> Mainly, that I'm having trouble parsing the documentation's explanation of
> dkim_sign_headers entries [0]. I can see 4 cases:
>
> * no prefix: sign the first instance of the named header or absence of it?
>
> * = prefix: sign all instances of the named header, only if present?
>
> * + prefix: sign all instances of the name header or the absence of it?
>
> * repeated header name: sign up to n instances or the absence of it?
>
> Therefore, if following the RFC (which suggests headers "should" be signed
> "if they are present" [1]) there should be a lot more use of '=' in the
> default? Especially "Resent-*" fields which the default effectively kills
> the use of.

My understanding of DKIM signatures is that if you sign an instance of a
header and it's not present, you are effectively signing the fact that
the header is absent (this is called 'oversigning' in some
documentation). In theory there can be multiple instances of a header
and in the DKIM-Signature header each mention covers only one instance.
So if you list a header more than once, you're signing multiple
instances of it (in a defined order); if there's only one instance of a
header in the message you're signing but an extra one in DKIM-Signature,
you're 'oversigning' the header so that no new instances of it can be
added.

(In practice it's very rare and generally alarming to see multiple
instances of most headers.)

In Exim, the no-prefix case signs the header whether or not it's
present, so for present headers you're signing the first instance and
the absent headers you're signing the absence. An '=' prefix merely
signs an existing header without oversigning an absent one to block its
addition, and a + signs existing headers *plus* one additional instance
(and absent headers are signed once), meaning that no further instances
of the header can be added.

As you note, a sensible Exim default might be to use = a lot more than
the current settings. The current Exim default appears to break the DKIM
signature if your message goes through a mailing list or a re-sending
that's polite enough to add explicit headers, but leaves it unbroken if
the mailing list or resender is silent about it, which doesn't really
seem ideal.

> The modification to List-Id also leaves me wondering about "Sender". I was
> previously under the impression mailing lists used/modified this, but
> apparently not.

My impression is that Sender is relatively obscure now. It was
originally mostly used to identify a human who had sent the message 'on
behalf of' the From: address. In practice various mail clients and MTAs
would add a Sender: if they could identify that the submitter of the
message wasn't the From:. Most mailing lists didn't set a Sender:
because they weren't acting this way (or didn't consider themselves to
be).

These days I believe most MTA setups either block unauthorized From:
alterations entirely or don't really care about it, so don't force the
addition of Sender:. A typical IMAP client will let you set your From:
to whatever you want and then generally doesn't add any sort of Sender:,
because that's not what people want. (You can probably set your IMAP
client to add one by hand if you want to.)

> Finally (and more theoretical problem than practical...) I'm not clear
> of the value of the DKIM signature if it's the message itself that
> defines the extent of what is signed (not some DNS record for example)

The signing system decides what will be signed and what key to use, but
the key must be in the DNS, so in a way the extent of what to sign is
linked to the DNS. One of the things this does is preserve the freedom
of the signing system to sign different headers in different contexts,
without having receiving systems parse various things out of DNS.

- cks

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Fri, Nov 03, 2023 at 12:18:05PM -0400, Chris Siebenmann wrote:

> > The modification to List-Id also leaves me wondering about
> > "Sender". I was previously under the impression mailing lists
> > used/modified this, but apparently not.

> My impression is that Sender is relatively obscure now. It was
> originally mostly used to identify a human who had sent the message
> 'on behalf of' the From: address. In practice various mail clients
> and MTAs would add a Sender: if they could identify that the
> submitter of the message wasn't the From:. Most mailing lists didn't
> set a Sender: because they weren't acting this way (or didn't
> consider themselves to be).

I believe exim still adds a Sender header when a message is submitted
via stdin with the -f option (which can only happen when you're one
of the "trusted" users).

I should check what hapens when you do this with msmtp, the program
I task with the submission role.

--
Ian

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 3. novembra 2023 16:18:05 UTC používate? Chris Siebenmann via Exim-users <exim-users@lists.exim.org> napísal:

>(In practice it's very rare and generally alarming to see multiple
>instances of most headers.)

AFAIK it was way to trick MUAs to show different value in eg.
From: or Subject: fields. Without oversign, some MUAs will
even show that message as with valid DKIM... Nowadays
it is IMO considered as sender/signer configuration mistake
(do not oversign crucial headers).

>In Exim, the no-prefix case signs the header whether or not it's

Yes, in enough recent version it is enough configurable, but
requires to define own "rule" for headers selection to sign.

>As you note, a sensible Exim default might be to use = a lot more than
>the current settings.

IMO select proper defaults is hard, as it depends. Old DKIM RFC defined
exact headers, recent version step down from exact list and is vague in
that. AFAIK there are two defaults defined as macros, and both are based
on old RFC headers list, but IMO no one is really usable as is.

If one select too few headers to sign, message can be resend modified,
but DKIM still can be valid. If one signs/oversigns too many headers,
legitimate flow can break DKIM, and message can have delivery
problem. Especially in general purpose case, it can be hard to satisfy
all flows...

As it is hard to define universal headers list (that is as i understand that
RFC's step down too), it can be worth to choose another approach for
exim default:

+ make that headers list unset (empty) by default
+ force admins to define own list -- do not sign & log panic if unset, or
even strong, consider it as config error and leave message in queue

And leave current macros just as examples...

>My impression is that Sender is relatively obscure now. It was

It is not common, but it has reason/usage even nowadays -- at least
to have track, who spoofed (possible legitime) From: header. In my
setup, if Sender: appears in message, it is not considered suspicious
(from outside) and i oversign it (from inside).

>These days I believe most MTA setups either block unauthorized From:
>alterations entirely or don't really care about it, so don't force the
>addition of Sender:.

IMO that is not MUA task, MUA has no way to know anything about
which addresses i (user) can use. And, mail is not limited to be send
from advanced MUA, i often compose and send emails from shell or
Python/PHP (which technically is MUA too) without any limitations.
Due that I force From:/Sender: checks at MSA, which has all needed
knowledge for particular authenticated user. As result, no one can
use spoofed nor duplicit From:, Sender: and some other headers
(with some exceptions, but limited in rate).

AFAIK exim adds Sender: header by default when From: differs
from calling user (notSMTP) and it is configurable. It has some
options for that for messages received over SMTP too, check docs
for details.

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Fri, 3 Nov 2023, Chris Siebenmann via Exim-users wrote:

> > I think the PostgreSQL recommendation seems reasonable, but the doc leaves
> > me with some questions/ambiguities.
> >
> > Mainly, that I'm having trouble parsing the documentation's explanation of
> > dkim_sign_headers entries [0]. I can see 4 cases:
> >
> > * no prefix: sign the first instance of the named header or absence of it?
> >
> > * = prefix: sign all instances of the named header, only if present?
> >
> > * + prefix: sign all instances of the name header or the absence of it?
> >
> > * repeated header name: sign up to n instances or the absence of it?
> >
> > Therefore, if following the RFC (which suggests headers "should" be signed
> > "if they are present" [1]) there should be a lot more use of '=' in the
> > default? Especially "Resent-*" fields which the default effectively kills
> > the use of.
>
> My understanding of DKIM signatures is that if you sign an instance of a
> header and it's not present, you are effectively signing the fact that
> the header is absent (this is called 'oversigning' in some
> documentation).

Thanks, this email is helpful. I think a useful addition to the Exim docs
would be to explain "oversign" as it's used without explanation, and it's
not in the RFC4871.

It seems the docs would be much clearer if it just listed the cases. The
"name is repeated" case also seems obscure and not practical to use for
anything?

[...]
> As you note, a sensible Exim default might be to use = a lot more than
> the current settings.

Yes the default is feeling very un-sensible as my understanding increases!
Especially as it doesn't match the RFC, either.

I had tended to assume the default was a safe choice to get started.

[...]
> > The modification to List-Id also leaves me wondering about "Sender". I was
> > previously under the impression mailing lists used/modified this, but
> > apparently not.
>
> My impression is that Sender is relatively obscure now. It was
> originally mostly used to identify a human who had sent the message 'on
> behalf of' the From: address. In practice various mail clients and MTAs
> would add a Sender: if they could identify that the submitter of the
> message wasn't the From:.

Thanks, yes I remember now experiencing it in combinations of Alpine,
/usr/bin/sendmail and exim -- I had to avoid it to avoid Gmail recipients
stating the message was "on behalf of..." and this makes sense now.

I'm unsure of the implication of multiple "Sender" headers in signing, but
am using '=' on this header for now.

As seems to be touched on elsewhere in this thread, I wonder if proper
handling of "Sender" is part of the key to logical handling of forwarding
(like .forward files).

[...]
> > Finally (and more theoretical problem than practical...) I'm not clear
> > of the value of the DKIM signature if it's the message itself that
> > defines the extent of what is signed (not some DNS record for example)
>
> The signing system decides what will be signed and what key to use, but
> the key must be in the DNS, so in a way the extent of what to sign is
> linked to the DNS. One of the things this does is preserve the freedom
> of the signing system to sign different headers in different contexts,
> without having receiving systems parse various things out of DNS.

Ah yes, sorry I missed the obvious there.

So it's up to the recipient to decide what 'level' of signing it trusts
for certain operations -- and recipients may decide differently.

Thanks

--
Mark

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/