[exim] Re: List headers [Was: DKIM does not work]
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-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: List headers [Was: DKIM does not work]
> 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-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: List headers [Was: DKIM does not work]
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-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: disclaimer + DKIM does not work (reopened)
Le 30/10/2023 à 11:09, Jeremy Harris via Exim-users a écrit : On 30/10/2023 09:42, brunoc68 via Exim-users wrote: Looking at the description of the transport option "size_addition", I understand that the size of the message is sent by smtp before the message is processed by the filter. I am not sure about my understanding of this option. Could that be a possible source of the error I obtain ? Marginally possible. It would require that the receiving system uses the SIZE passed with the MAIL TO for its dkim verification but *not* for its actual reception of the message. Pretty unlikely, but you could test by setting the option to -1 (which would mean it couldn't possibly do that). I checked several configuration of the "size_addition" option and it does not work. I also sent an email to another of my servers running both Exim and spamassassin as well. I got the following, clearly telling DKIM_INVALID : DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ciarem.fr; s=dkim; 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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KqNN2YxYpsbEJ+qOKn2J3M0huRA1QxmBanUfyMElrc0=; b=LypOiBYcyrZvGx6xEIsFbc4/L8 Hu1UMcQH/SXtR4R6fRYqbx7yPMOzXsN83LVsiIFTNF+LUdFJrEwIFxOF/Kz30CB86x96BMZwsHy7s JxlHdFBdnmD7rgc21vLV/dmavvgHQaPnAw2TCCxpv84qvOivKn0CfBaWyRXXkRBXxVzVuW658QMjQ OjR9rLZ1Z4wToQ9tm43S08rLZivFGiWp5Rtz8HGeydmmmWAolYEsvJmJwCFdMeR3DWxXtdp7xjSmL /d1Ot6IgZUJef9vfxcJTG8PoPJvxO09Jche5xn4zQjjcw51xqO4w6ut4zILH/qW/tyGxo9VnH9ov3 Bv0slp7A==; X-Spam-Status: No, score=3.3 required=5.0 tests=*DKIM_INVALID*,DKIM_SIGNED, HTML_IMAGE_ONLY_08,HTML_MESSAGE,MIME_QP_LONG_LINE,RDNS_NONE,SPF_HELO_PASS, SPF_PASS,T_REMOTE_IMAGE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED, URIBL_DBL_BLOCKED_OPENDNS autolearn=disabled version=3.4.0 Jeremy, you told me what I sent to your private email was ok, but on my side I can not reproduce any recipient (mail-tester.com, gmail.com, another of my server) where the DKIM signature is valid... -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: List headers [Was: DKIM does not work]
Dňa 3. novembra 2023 16:18:05 UTC používateľ Chris Siebenmann via Exim-users 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-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
