On 2021-11-24 04:01, Martijn van Duren wrote:
On Tue, 2021-11-23 at 08:47 -0800, Paul Pace wrote:
Hello!

I have an Ubuntu 18.04 server running Postfix 3.3 that relays through a
local OpenSMTPD mail relay on OpenBSD 7.0. Messages sent from system
messages and directly from mail command are signed by dkimsign as
expected.

Messages sent from letstencrypt run through cron.weekly are not being
signed by dkimsign with the expected domain. Log entries for correctly
signed and incorrectly signed messages are identical on both client and
relay server.

Here are the key portions of the header in the received inbox for the
cron.weekly job:


DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021;
bh=rNFy7e0QC/J
        YFcHTI8wUywlRSY3eJ4LLLsOZrSC0XBc=; h=date:subject:to:from;
d=example.com; b=KqmB7rxJfpLcF6Nif/4bQRAbcQDDhVmFh+8KDeCqc9ujlr8ogK7...
Received: from relayclient.example.com (<unknown> [172.16.13.2])
        by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
        for <u...@example.net>;
        Sun, 14 Nov 2021 06:47:03 -0800 (PST)
Received: by relayclient.example.com (Postfix)
        id 881F75F401; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
Delivered-To: r...@relayclient.example.com
Received: by relayclient.example.com (Postfix, from userid 0)
        id 81D885F402; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
 From: r...@relayclient.example.com (Cron Daemon)
To: r...@relayclient.example.com
Subject: Cron <root@relayclient> test -x /usr/sbin/anacron || ( cd / &&
run-parts --report /etc/cron.weekly )
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env:
<PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
Message-Id: <20211114144703.81d885f...@relayclient.example.com>
Date: Sun, 14 Nov 2021 06:47:03 -0800 (PST)


Note in this above headers that d=example.com and expected is
d=relayclient.example.com

Here are the key portions of the headers in the received inbox from the
same client but for some other system message:


DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021;
bh=r8XLAjeCvrx
        jCndiJeywanw7UmGo9LRF4gIb07HheJc=; h=date:to:from:subject;
        d=relayclient.example.com;
b=QfD3av5+JxEZyCgzeZ7GcnhIf3/sMmeCNDtEvz/4/hGZf...
Received: from relayclient.example.com (<unknown> [172.16.13.2])
        by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
        for <u...@example.net>;
        Sat, 20 Nov 2021 06:40:29 -0800 (PST)
Received: by relayclient.example.com (Postfix)
        id AFFC95E476; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
Delivered-To: r...@relayclient.example.com
Received: by relayclient.example.com (Postfix, from userid 0)
        id A961A5F42E; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
Subject: unattended-upgrades result for relayclient.example.com: True
 From: r...@relayclient.example.com
To: r...@relayclient.example.com
Auto-Submitted: auto-generated
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20211120144029.a961a5f...@relayclient.example.com>
Date: Sat, 20 Nov 2021 06:40:29 -0800 (PST)


Note in this above headers that d=relayclient.example.com, as expected.

Here is smtpd.conf:


pki int_net cert "/etc/ssl/176.16.13.1.crt"
pki int_net key "/etc/ssl/private/smtp.example.com.key"

table aliases file:/etc/mail/aliases

filter "dkimsign_loc_rsa" proc-exec "filter-dkimsign \
-d smtp.example.com -s 10172021 \
-k /etc/mail/dkim/10172021.rsa.key" user _dkimsign group _dkimsign

filter "dkimsign_int_rsa" proc-exec "filter-dkimsign \
-d example.com \
-d smtp.example.com \
-d relayclient.example.com
-s 10172021 -k /etc/mail/dkim/10172021.rsa.key" user _dkimsign group
_dkimsign

listen on socket
listen on lo0 filter "dkimsign_loc_rsa"
listen on vio1 tls pki int_net filter "dkimsign_int_rsa"

action "local_mail" mbox alias <aliases>
action "local_redirect" relay host smtp+notls://127.0.0.1:25
action "outbound" relay

match from socket action "local_redirect"
match for local action "local_mail"
match from any for any action "outbound"


The vio1 interface is on the private network and access is controlled
through PF.

Thank you!

Paul

I can't reproduce this in the most simple form and I don't notice
anything in the code that might point to a bug of this kind.
(tried with smtp(1) and a single filter with the subdomains in the
same order as you have)

What the code does: it starts with the first domain in the list (in this
case example.com) and then gets the domain part of the first e-mail
address in the from-list and compares it to all the specified domains,
if a match is found that domain is used. If none is found labels are
stripped from the from-domain until a match is found. If none is found
at all we stick with the first domain in the list.

Since I highly doubt that example.com is the domain you're signing with
my primary suspicion is that there's a discrepancy between the from-
domain and the -d (which causes it to use the default name of
example.com), but that this mismatch is obfuscated because of your
redaction in this mail.

If that's not the case, please provide me with a simple proof of
concept, so that I can analyse this further.

martijn@

Hi Martin,

Apologies for taking so long to get back on this, but the messages still inbox, so technically not breaking anything. However, I wanted to ask:

The only time dkimsign is not using the correct domain for 'd=' is when the From: header looks exactly like this:

From: r...@relayclient.example.com (Cron Daemon)

Versus:

From: r...@relayclient.example.com

Is it possible that somehow the '(Cron Daemon)' on the end is causing an issue? Unfortunately, I cannot read source to answer this question myself, but I'm not clear that format is RFC compliant, as I've only previously seen '<usern...@example.com>', 'usern...@example.com', or 'Agent Smith <usern...@example.com>' formats in the RFCs. I really can't find any other difference and I can send the unredacted headers, if this isn't the issue.

Thank you,


Paul

Reply via email to