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@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
