Re: Sendmail and DKIM for bounce messages?

Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 3/12/25 10:52 AM, Otto J. Makela wrote:

We have servers which send out emails using a client domain:
clients have set up SPF records that allow us to do this, and DKIM
keys have been set up so our Sendmail/OpenDKIM smarthost setup can
sign the messages correctly. When mail gets delivered normally,
everything is OK.

>
I don't know if it matters, but I feel I should ask, do the SPF
records authorize the originating servers and / or the smarthost?

As I said, clients have added our sendmail-based server (smarthost) in
their SPF record (SPF does not come into play with the mail generating
servers that are hosted with us, we use a simple IP-address based
access table to permit them to send emails to our smarthost).

However, there are issues when message bounces are generated for
our smarthost, and it tries to deliver it to the sender the
customer used.

>
Please clarify which system is rejecting the incoming message and
which system is the system obliged to send the DSN? [...]
Or is the recipient's MX not accepting the message from the smart host
and thus the smart host is obliged to generate the DSN?

This. As our smarthost tries to deliver the email to whatever receiving
system has been specified, if that receiving system gives a 500-series
answer, the only thing to do for the smarthost is to generate a bounce.

The messages the client servers send out to our smarthost typically have
a "SMTP Sender" and "From" that is deliverable to the client email
system but includes "noreply" in it to try to preclude humans from
replying there. Typically something like "noreply.system@client.domain"

Apparently, the setup I currently have does not DKIM sign messages
where the sender is the classic email bounce empty sender <>

>
I don't remember the last time I saw a DKIM signed DSN.  But I don't
remember ever looking.

Apparently this is the new normal, at least for Microsoft and perhaps
also for Google. Unfortunately, having a dual IPv4/IPv6 hosted smarthost
seems to play a part here — I guess the assumption is that if you are
able to make IPv6 work you are Teh Master of Teh Internet, and will
happily jump through all the other hoops they set up.

This means that messages will languish in the mail queue for days if
the client's email systems (typically M365, Google or some such large
email handler) will not accept them, and then cause double bounces.

>
Please share a sample rejection reason from the recipient's MX.

Typical case is attempting to send a bounce to a M365-hosted client
client.domain, with SMTP Sender <> and headers something like:

Return-Path: <>
From: Mail Delivery Subsystem <MAILER-DAEMON>
To: <noreply.system@client.domain>

(But apparently currently missing DKIM-signing)
M365 typically rejects the message with the temporary failure:

450 4.7.26 Service does not accept messages sent over IPv6
    [2001:708:10:6004::22] unless they pass either SPF or DKIM validation
    (message not signed) (S825). [Name=Protocol Filter Agent][AGT=PFA]
    [MxId=11BAC97D88481505] [DU6PEPF00009526.eurprd02.prod.outlook.com
    2025-03-19T11:12:58.795Z 08DD64BEC83A4096]

You'll notice the error message says "SPF or DKIM" but in my experience
with IPv6 this means "SPF and DKIM". As noted, SPF is correct but our
smarthost appears currently not to generate a DKIM signature for bounces.

I'd think that for any message; DSN or otherwise, to get stuck in
queue until it expires, the receiving system would have to return
temporary failures.  If the receiving system returned permanent
failures, the DSN would turn into a double bounce immediately.

Indeed, as I said, it'll sit in the smarthost queue (generating
tempfails) until the default 5 days have passed, and then our smarthost
generates a proper double bounce. To yours truly.

I seem to remember a draft-level proposal to how such bounces should
be signed (since the To/From fields are somewhat wonky here), but
apparently my searching skills are lacking in this respect.

Does anyone remember seeing stuff like this?

--
   /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
  /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
 /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */