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?

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?

Is the smart host not accepting the message from the original sending
host and thus the original sending host is obliged to generate 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?

You indicate that the DSN is from the null reverse path and going to the original envelope sender.

What are the From: and To: headers in the DSN?

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.

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.

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.

I'm trying to deduce the actual email flow and full responses at each
step and think about how SPF / DKIM / DMARC would influence things.

Is this just some configuration option I need to change, or what?

I don't know.

I need more specifics to be able to speculate.

The only thing that comes to mind is that the DSN recipient's receiving
system is rate limiting as an anti-spam measure and the drain queue rate
is slower than the queue fill rate, thus the backup -> eventual overflow
of DSNs in the queue.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.03.2025 17:52 Uhr Otto J. Makela wrote:

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.

Is SPF valid for those messages?
SPF records must exist for the hostname in the EHLO command.

IIRC it is possible to send bounces using valid SPF only, but this
might be different for different sites, as MS and Google seem to have
variable rules for different sites.

--
kind regards
Marco

Send spam to 1741798372muell@stinkedores.dorfdsl.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/14/25 4:40 AM, Marco Moock wrote:

SPF records must exist for the hostname in the EHLO command.

I agree that this has become a common enough requirement.

But my understanding is that it's a perversion of the original intention
behind SPF.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Claus Aßmann wrote:

Otto J. Makela wrote:

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

If you use a milter to create DKIM signatures then you have to send
your bounces via a sendmail process that runs that milter.

Indeed. I currently just have

INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@127.0.0.1')dnl

in my sendmail.mc to milter stuff through the locally running opendkim,
and clearly this does not get invoked when generating bounces.

Does anyone know how I am supposed to invoke opendkim to make a
signature in the case of bounces, where the mail message fields do
not make it immediately obvious what domain should be used?

Apparently, this is possible (but disabled by default) on Postfix:
https://www.postfix.org/MILTER_README.html

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.

Isn't that a nice sh!tty requirement made up by the biggest spam
sources? Isn't just SPF enough to fullfill their random (and useless) requirements?

Made a longer followup to another thread here, but apparently using an
IPv6 interface (as default like Linux is prone to do) somehow makes a difference for them.

I've even considered hard-wiring these mail recepients to only use IPv4,
but of course doing this is painful since M365 keeps shifting around so
much.

--
/* * * 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 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

om@iki.fi (Otto J. Makela) wrote:

I've even considered hard-wiring these mail recepients to only use
IPv4, but of course doing this is painful since M365 keeps shifting
around so much.

I actually just did this, inserted into mailertable a line like

client.domain esmtp:[ipv4-address-of-their-m365-mx]

and then ran

/usr/lib/sendmail -qRclient.domain

which nicely transferred the outstanding queue of messages from
mailer-daemon to their server. "Of course" they'll accept unsigned
messages if you are connecting over IPv4 :-/

Unfortunately, this horrible kludge is not something one really can
leave in place for an extended period.
--
/* * * 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 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.03.2025 14:46 Uhr Otto J. Makela wrote:

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).

If MAIL FROM: is <>, the SPF will be checked against the hostname in
EHLO. Check which hostname is being used there and create and SPF for
it.

--
kind regards
Marco

Send spam to 1742391985muell@stinkedores.dorfdsl.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marco Moock <mm@dorfdsl.de> wrote:

On 19.03.2025 14:46 Uhr Otto J. Makela wrote:

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).

If MAIL FROM: is <>, the SPF will be checked against the hostname in
EHLO. Check which hostname is being used there and create and SPF for
it.

Dammit, should have remembered that.
I've now added the appropriate SPF record, let's see if it makes a difference. --
/* * * 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 * * * * * * */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)