Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-02-22 Thread Martijn van Duren
On Fri, 2022-01-28 at 00:09 +0100, Martijn van Duren wrote:
> On Mon, 2022-01-24 at 16:20 +0100, Tim van der Molen wrote:
> > Hi,
> > 
> > Martijn van Duren (2022-01-23 20:13 +0100):
> > > >  From: r...@relayclient.example.com (Cron Daemon)
> > > 
> > > According to RFC5322 section 3.4[0] this is not a valid e-mail format.
> > 
> > Just to point out this actually is valid. Text in parentheses is a
> > comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
> > which describes the format used above:
> > 
> >   Note: Some legacy implementations used the simple form where the
> >   addr-spec appears without the angle brackets, but included the
> >   name of the recipient in parentheses as a comment following the
> >   addr-spec.  Since the meaning of the information in a comment is
> >   unspecified, implementations SHOULD use the full name-addr form of
> >   the mailbox, instead of the legacy form, to specify the display
> >   name associated with a mailbox.  Also, because some legacy
> >   implementations interpret the comment, comments generally SHOULD
> >   NOT be used in address fields to avoid confusing such
> >   implementations.
> > 
> > Best,
> > Tim
> 
> Thanks for pointing this one out, it made me take a closer look at the
> spec. So when I originally responded I was only thinking in terms of
> what characters are used in a domain name, but the " (Cron Daemon)" part
> is not to be interpreted as domain characters, but a CFWS (or comment
> folding whitespace). This means that it should not be returned by
> osmtpd_mheader_from_domain() as part of the domain. So it is valid
> syntax, but I shouldn't have returned it when comparing against the
> known domain list. Similarly there were also a couple of FWS that I
> could ignore.
> 
> As for Paul's remark "SHOULD NOT" when it comes to this syntax: It's
> part of the current syntax (e.g. not obsolete), so I don't see any
> reason not to. Sorry for the confusion.
> 
> I have the following changes lined up in my repo[0]:
> - Fix a couple of memory leaks in error paths (pointed out by
>   Peter)
> - Add support for -D file, where file contains one domain per line. All
>   other rules from -d apply. (requested by Mischa and Renaud)
> - Fix FWS and CFWS issues when parsing a domain (pointed out by
>   Paul/Tim)
> 
> If people could help me test the latest code (or even check the diffs
> of revision 75-HEAD) that would help prepare for a new release.
> 
> martijn@
> 
> [0] http://imperialat.at/dev/filter-dkimsign/

Did anyone test this yet? I would like to have other people test this
before creating a new release.



Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-27 Thread Martijn van Duren
On Mon, 2022-01-24 at 16:20 +0100, Tim van der Molen wrote:
> Hi,
> 
> Martijn van Duren (2022-01-23 20:13 +0100):
> > >  From: r...@relayclient.example.com (Cron Daemon)
> > 
> > According to RFC5322 section 3.4[0] this is not a valid e-mail format.
> 
> Just to point out this actually is valid. Text in parentheses is a
> comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
> which describes the format used above:
> 
>   Note: Some legacy implementations used the simple form where the
>   addr-spec appears without the angle brackets, but included the
>   name of the recipient in parentheses as a comment following the
>   addr-spec.  Since the meaning of the information in a comment is
>   unspecified, implementations SHOULD use the full name-addr form of
>   the mailbox, instead of the legacy form, to specify the display
>   name associated with a mailbox.  Also, because some legacy
>   implementations interpret the comment, comments generally SHOULD
>   NOT be used in address fields to avoid confusing such
>   implementations.
> 
> Best,
> Tim

Thanks for pointing this one out, it made me take a closer look at the
spec. So when I originally responded I was only thinking in terms of
what characters are used in a domain name, but the " (Cron Daemon)" part
is not to be interpreted as domain characters, but a CFWS (or comment
folding whitespace). This means that it should not be returned by
osmtpd_mheader_from_domain() as part of the domain. So it is valid
syntax, but I shouldn't have returned it when comparing against the
known domain list. Similarly there were also a couple of FWS that I
could ignore.

As for Paul's remark "SHOULD NOT" when it comes to this syntax: It's
part of the current syntax (e.g. not obsolete), so I don't see any
reason not to. Sorry for the confusion.

I have the following changes lined up in my repo[0]:
- Fix a couple of memory leaks in error paths (pointed out by
  Peter)
- Add support for -D file, where file contains one domain per line. All
  other rules from -d apply. (requested by Mischa and Renaud)
- Fix FWS and CFWS issues when parsing a domain (pointed out by
  Paul/Tim)

If people could help me test the latest code (or even check the diffs
of revision 75-HEAD) that would help prepare for a new release.

martijn@

[0] http://imperialat.at/dev/filter-dkimsign/



Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-27 Thread Paul Pace

On 2022-01-26 19:24, Ryan Kavanagh wrote:

On Wed, Jan 26, 2022 at 12:48:26PM -0800, Paul Pace wrote:

I'm trying to figure by going backwards where in the
Ubuntu/Debian/cron chain of packaging, configuring, compiling, or
coding this format actually comes from but I have a feeling this ends
up being a long goose chase.


Debsources [0] should help you catch the proverbial goose quickly
enough.

I'm guessing that the most likely source is line 507 of do_command.c in
the cron source package [1], unless it's getting set somewhere using
MAILFROM, in which case, likely [2]. There are a few other potential
matches [3].

Best,
Ryan

[0] https://sources.debian.org/
[1] 
https://sources.debian.org/src/cron/3.0pl1-137/do_command.c/?hl=507#L507
[2] 
https://sources.debian.org/src/cron/3.0pl1-137/debian/patches/features/Add-MAILFROM-environment-variable.patch/?hl=125#L125

[3] https://codesearch.debian.net/search?q=package%3Acron+Cron+Daemon

Very helpful!

I know very little about the depths of development work on these kinds 
of tools, and it looks like cron is maintained separately for each 
project, and had been somewhat neglected by Debian. That patch you 
linked was submitted with a bug (isn't that what every dev wishes for?) 
but then sat for three years.


Also learned that Debian uses GitLab for development work on "salsa".

Anyway, as best I can tell that patch made it to a salsa commit[1] and 
maybe it shows up one day in Ubuntu with the following new feature:


+If MAILFROM is defined, the sender email address is set to MAILFROM. 
Otherwise

+mail is sent as "root (Cron Daemon)".

So until then options are to fix it with the local MTA or just live with 
it.


Thank you,


Paul

[1] 
https://salsa.debian.org/debian/cron/-/commit/1d904fb79cfc732cdda0c45800258580c727555b




Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-26 Thread Ryan Kavanagh
On Wed, Jan 26, 2022 at 12:48:26PM -0800, Paul Pace wrote:
> I'm trying to figure by going backwards where in the
> Ubuntu/Debian/cron chain of packaging, configuring, compiling, or
> coding this format actually comes from but I have a feeling this ends
> up being a long goose chase.

Debsources [0] should help you catch the proverbial goose quickly
enough.

I'm guessing that the most likely source is line 507 of do_command.c in
the cron source package [1], unless it's getting set somewhere using
MAILFROM, in which case, likely [2]. There are a few other potential
matches [3].

Best,
Ryan

[0] https://sources.debian.org/
[1] https://sources.debian.org/src/cron/3.0pl1-137/do_command.c/?hl=507#L507
[2] 
https://sources.debian.org/src/cron/3.0pl1-137/debian/patches/features/Add-MAILFROM-environment-variable.patch/?hl=125#L125
[3] https://codesearch.debian.net/search?q=package%3Acron+Cron+Daemon

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A



Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-26 Thread Paul Pace

On 2022-01-24 07:20, Tim van der Molen wrote:

Hi,

Martijn van Duren (2022-01-23 20:13 +0100):

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

According to RFC5322 section 3.4[0] this is not a valid e-mail format.


Just to point out this actually is valid. Text in parentheses is a
comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
which describes the format used above:

  Note: Some legacy implementations used the simple form where the
  addr-spec appears without the angle brackets, but included the
  name of the recipient in parentheses as a comment following the
  addr-spec.  Since the meaning of the information in a comment is
  unspecified, implementations SHOULD use the full name-addr form 
of

  the mailbox, instead of the legacy form, to specify the display
  name associated with a mailbox.  Also, because some legacy
  implementations interpret the comment, comments generally SHOULD
  NOT be used in address fields to avoid confusing such
  implementations.

Best,
Tim


After the email from Martjin I posted a question to Server Fault[1], 
because I find both 5321 and 5322 I often misread, and based on some 
helpful responses it is not clear to me that this is an acceptable From: 
syntax. Even if it is, it seems to be at best a SHOULD NOT, so I'm 
trying to figure by going backwards where in the Ubuntu/Debian/cron 
chain of packaging, configuring, compiling, or coding this format 
actually comes from, but I have a feeling this ends up being a long 
goose chase.


Thank you,

Paul

[1] https://serverfault.com/q/1090902/153188



Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-24 Thread Tim van der Molen
Hi,

Martijn van Duren (2022-01-23 20:13 +0100):
> >  From: r...@relayclient.example.com (Cron Daemon)
> 
> According to RFC5322 section 3.4[0] this is not a valid e-mail format.

Just to point out this actually is valid. Text in parentheses is a
comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
which describes the format used above:

  Note: Some legacy implementations used the simple form where the
  addr-spec appears without the angle brackets, but included the
  name of the recipient in parentheses as a comment following the
  addr-spec.  Since the meaning of the information in a comment is
  unspecified, implementations SHOULD use the full name-addr form of
  the mailbox, instead of the legacy form, to specify the display
  name associated with a mailbox.  Also, because some legacy
  implementations interpret the comment, comments generally SHOULD
  NOT be used in address fields to avoid confusing such
  implementations.

Best,
Tim



Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-23 Thread Martijn van Duren
On Sun, 2022-01-23 at 09:29 -0800, Paul Pace wrote:
> 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 ( [172.16.13.2])
> > >   by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358
> > > (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
> > >   for ;
> > >   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  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: 
> > > X-Cron-Env:
> > > 
> > > X-Cron-Env: 
> > > X-Cron-Env: 
> > > Message-Id: <2024144703.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 ( [172.16.13.2])
> > >   by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1
> > > (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
> > >   for ;
> > >   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 
> > > 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 

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2022-01-23 Thread Paul Pace

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 ( [172.16.13.2])
by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
for ;
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  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: 
X-Cron-Env:

X-Cron-Env: 
X-Cron-Env: 
Message-Id: <2024144703.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 ( [172.16.13.2])
by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
for ;
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 
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 

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2021-11-24 Thread Martijn van Duren
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 ( [172.16.13.2])
>   by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358 
> (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
>   for ;
>   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  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: 
> X-Cron-Env: 
> 
> X-Cron-Env: 
> X-Cron-Env: 
> Message-Id: <2024144703.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 ( [172.16.13.2])
>   by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1 
> (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
>   for ;
>   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 
> 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 

dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

2021-11-23 Thread Paul Pace

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 ( [172.16.13.2])
	by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358 
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)

for ;
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  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: 
X-Cron-Env: 


X-Cron-Env: 
X-Cron-Env: 
Message-Id: <2024144703.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 ( [172.16.13.2])
	by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1 
(TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)

for ;
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 
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