> On Oct 8, 2022, at 12:59, Wietse Venema <wie...@porcupine.org> wrote:
>
> Dan Mahoney:
>> Hey there all,
>>
>> We have a couple of recipient canonical maps that do things like
>> transform firstname_lastname into username (i.e. dan_mahoney -->
>> dmahoney), also handle things like mapping people's former names
>> into current names.
>>
>> This is useful where a user wants to have one canonical spamassassin
>> settings folder, WHICH SPAMASS-MILTER GETS BY LOOKING AT THE LEFt
>> HAND SIDE OF THE ADDRESS. So we clearly want spamass-milter to
>> run after this rewriting happens.
>
> [sorry for shouting, I captalized some text that is problematic.]
>
> The system described in the capitalized text should not rely on the
> message HEADER to determine who an email message is for.
>
> For example, this message is sent to your email address, but you
> are not in any recipient header. You are in the envelope.
>
> A proper spam filter looks at the ENVELOPE recipient address to
> determine who an email message is for.
>
> Canonicalizing the envelope recipient before the DKIM check would
> not cause the DKIM check to fail, because DKIM looks at message
> content. It also does affect SPF, because SPF looks at where mail
> comes from, not recipients.
>
> There is no problem with canonical mapping before DKIM check, as
> long as the mapping is limited to the envelope. And it is perfetly
> legitimate to use virtual_alias_mnaps for that.
>
> It took a few iterations before I think I hit the root problem.
Sorry, I think we've not solved this yet.
Here I've sent an email to dan_maho...@foo.org, which gets mapped to
dmaho...@foo.org, and postfix rewrites this because of canonical recipient
headers. This is also where it does the spam check.
You can see that the DKIM signature relies on the rewritten "to" line, and thus
fails.
ARC-Authentication-Results: i=1; mx.pao1.foo.org; dmarc=pass (p=none dis=none)
header.from=prime.gushi.org; spf=pass smtp.mailfrom=prime.gushi.org; dkim=fail
(2048-bit key; unprotected) header.d=gushi.org header.i=@gushi.org
header.b=IPBHz9fA reason="signature verification failed"
Authentication-Results: mx.pao1.foo.org; dmarc=pass (p=none dis=none)
header.from=prime.gushi.org
Authentication-Results: mx.pao1.foo.org; spf=pass smtp.mailfrom=prime.gushi.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.foo.org 09D4A3AB008
Authentication-Results: mx.pao1.foo.org;
dkim=fail reason="signature verification failed" (2048-bit key;
unprotected) header.d=gushi.org header.i=@gushi.org header.b=IPBHz9fA
Received: from smtpclient.apple ([IPv6:2601:602:87f:b05d:386e:8ecd:c196:faec])
(authenticated bits=0)
by prime.gushi.org (8.16.1/8.16.1) with ESMTPSA id 298LN79I090633
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
for <dan_maho...@foo.org>; Sat, 8 Oct 2022 14:23:09 -0700 (PDT)
(envelope-from d...@prime.gushi.org)
DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 298LN79I090633
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org;
s=prime2014; t=1665264189;
bh=KoVg/zDS2Aw+ZgBDW7PZEDdzI9hiIqIo92irX0ovrKQ=;
h=From:Subject:Date:To;
z=From:=20Dan=20Mahoney=20<d...@prime.gushi.org>|Subject:=20Test=20
for=20DKIM|Date:=20Sat,=208=20Oct=202022=2014:23:02=20-0700|To:=20
dan_maho...@foo.org;
b=IPBHz9fA08FLnU6X0bs/3xS/TUWJHJApjSbjKKKQ9TniH2tPcwCuSF1z0ueC5JwPy
achgfmZIPW5efwt28t+40X+qaLmv+KyiBct20ra/mIo76Biqwv10mfAehnBkjehyXU
Lg9CYk1xSBu6Uu03iOximuKWC2UIT8/ejiu53aWQcjbXa47hkxVxPTrRVmLtgOk4qE
aplnW29Jd4nStbZdfP5w9gN082UtpWdJMhgYD4UyhnPIjsdCJ9t8N7sTr/X73k0jbX
+DN8HOhkNazW2B22arV1nz5ZwsgSmiskJsiYiWX5CPWlsRTJU8iXLHk+UKMN4MFjAJ
/PXdE5cjta96g==
X-Authentication-Warning: prime.gushi.org: Host
[IPv6:2601:602:87f:b05d:386e:8ecd:c196:faec] claimed to be smtpclient.apple
From: Dan Mahoney <d...@prime.gushi.org>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Test for DKIM
Message-Id: <86036335-5b86-4b04-83e2-6b2cdbfe6...@prime.gushi.org>
Date: Sat, 8 Oct 2022 14:23:02 -0700
To: dmaho...@foo.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
DKIM Test
===
The spam check *wants* to know dmahoney@, not dan.mahoney@, dan_mahoney@,
dan.mymaidenname@. Both need to run at receive-time, so they can reject rather
than generating bounces. So rewriting the envelope recipient is working, but
this is *also* rewriting the body. (And I checked, it does look at the
envelope-sender, not the body).
If possible, could we move the body rewriting (if we do it at all) to the point
at which we deliver on to our mailbox server?
You've suggested adding the rewrite later on (on the mailbox server) or perhaps
not at all, but right now, we've come to rely on the canonicalization knowing
the true username.
The suggested "sendmail -bv" script hack *might* suffice for this, though, but
this still doesn't jive with what you've said when the flow is:
"network -> smtpd(8)+milters ->cleanup(8)+milters -> queue file -> some
delivery agent."
There are two chains of "+milters" here -- which one is this milter getting
called as part of?
I'd probably be okay with not rewriting the body, but I would have to run it by
management first to see how it affected corporate optics.
Reading further, It also looks like we were using local_header_rewrite_clients
= static:all (config I inherited and left in place), which I should turn off,
and everything may magically work.
-Dan
>
> Wietse
