nullmailer crashing machines with endless loops

[hadmut]

Hi,

nullmailer crashed several mashines here, since it's configuration abilities are limited, and once things go wrong (e.g. because the mail relay doesn't accept the self-given DAEMON sender-adress), nullmailer will go into an endless loop of sending error messages, consuming all file space and inodes on disk and cpu.

Never ever send a delivery failure or confirmation mail for another delivery failure message.

It's an old an important rule to send status mails only for the first, the normal mail message, but never ever for anything beyond, because it creates endless loops.

[bruceg]

That is odd. The nullmailer-send program already guards against sending double bounces as described. Specifically, DSNs are generated with an empty sender address, and nullmailer-send does not generate a DSN for a message with an empty sender address (as of version 2.2).

What version are you running? Did you happen to keep the queue file for one of the looping messages?

[hadmut]

Nullmailer 1:2.1-5 as it comes with Ubuntu 18.04.

I had removed the full failed directory, where hundreds of thousands of mails had been produced, and as an emergency step, had removed them all, they were all of the same style. After killing nullmailer just a single one of these loop messages was kept in the outgoing spool, so to give you one example, I'll attach (and replace the target address with my own one since this is not to be published here) it.

[No, I can't attach. For some strange reason github doesn't let me upload the file 'We don't support that file type.' ??? even when giving it a .txt ending. Therefore I'll just paste it:]

#@[]

Received: (nullmailer pid 10874 invoked by uid 8); Sun, 29 Dec 2019 21:31:00 -0000 From: Message Delivery Subsystem [email protected] To: <#@[]> Subject: Returned mail: Could not send message Date: Sun, 29 Dec 2019 22:31:00 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1577655060.650142.10875"

--1577655060.650142.10875 Content-Type: text/plain; charset=us-ascii

This is the nullmailer delivery system. The message attached below could not be delivered to one or more of the intended recipients:

<[email protected]>

--1577655060.650142.10875 Content-Type: message/delivery-status

Reporting-MTA: x-local-hostname; speedy.fritz.box Arrival-Date: Sun, 29 Dec 2019 22:31:00 +0100

Final-Recipient: rfc822; [email protected] Action: failed Status: 5.1.7 Last-Attempt-Date: Sun, 29 Dec 2019 22:31:00 +0100 Remote-MTA: dns; mail.rackland.de Diagnostic-Code: SMTP; 501 5.1.7 Bad sender address syntax

--1577655060.650142.10875 Content-Type: message/rfc822

Received: (nullmailer pid 10871 invoked by uid 8); Sun, 29 Dec 2019 21:31:00 -0000 From: Message Delivery Subsystem [email protected] To: <> Subject: Returned mail: Could not send message Date: Sun, 29 Dec 2019 22:31:00 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1577655060.320945.10872"

--1577655060.650142.10875--

[hadmut]

I just again had a 3.5 G spool directory full of nullmailer endless loop messages like

#@[] [email protected]

Received: (nullmailer pid 20085 invoked by uid 8); Wed, 04 Mar 2020 23:28:32 -0000 From: Message Delivery Subsystem [email protected] To: <> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:32 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364512.765404.20086"

--1583364512.765404.20086 Content-Type: text/plain; charset=us-ascii

This is the nullmailer delivery system. The message attached below could not be delivered to one or more of the intended recipients:

<#@[]>

--1583364512.765404.20086 Content-Type: message/delivery-status

Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Arrival-Date: Thu, 05 Mar 2020 00:28:32 +0100

Final-Recipient: rfc822; #@[] Action: failed Status: 5.1.3 Last-Attempt-Date: Thu, 05 Mar 2020 00:28:32 +0100 Remote-MTA: dns; mail.rackland.de Diagnostic-Code: SMTP; 501 5.1.3 Bad recipient address syntax

--1583364512.765404.20086 Content-Type: message/rfc822

Received: (nullmailer pid 20082 invoked by uid 8); Wed, 04 Mar 2020 23:28:32 -0000 From: Message Delivery Subsystem [email protected] To: <#@[]> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:32 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364512.422024.20083"

--1583364512.765404.20086--

#@[]

Received: (nullmailer pid 20062 invoked by uid 8); Wed, 04 Mar 2020 23:28:30 -0000 From: Message Delivery Subsystem [email protected] To: <#@[]> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:30 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364510.445574.20063"

--1583364510.445574.20063 Content-Type: text/plain; charset=us-ascii

This is the nullmailer delivery system. The message attached below could not be delivered to one or more of the intended recipients:

<[email protected]>

--1583364510.445574.20063 Content-Type: message/delivery-status

Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Arrival-Date: Thu, 05 Mar 2020 00:28:30 +0100

Final-Recipient: rfc822; [email protected] Action: failed Status: 5.1.7 Last-Attempt-Date: Thu, 05 Mar 2020 00:28:30 +0100 Remote-MTA: dns; mail.rackland.de Diagnostic-Code: SMTP; 501 5.1.7 Bad sender address syntax

--1583364510.445574.20063 Content-Type: message/rfc822

Received: (nullmailer pid 20059 invoked by uid 8); Wed, 04 Mar 2020 23:28:30 -0000 From: Message Delivery Subsystem [email protected] To: <> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:30 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364510.132216.20060"

--1583364510.445574.20063--

[hadmut]

#@[] [email protected]

Received: (nullmailer pid 20065 invoked by uid 8); Wed, 04 Mar 2020 23:28:30 -0000 From: Message Delivery Subsystem [email protected] To: <> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:30 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364510.802252.20066"

--1583364510.802252.20066 Content-Type: text/plain; charset=us-ascii

This is the nullmailer delivery system. The message attached below could not be delivered to one or more of the intended recipients:

<#@[]>

--1583364510.802252.20066 Content-Type: message/delivery-status

Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Arrival-Date: Thu, 05 Mar 2020 00:28:30 +0100

Final-Recipient: rfc822; #@[] Action: failed Status: 5.1.3 Last-Attempt-Date: Thu, 05 Mar 2020 00:28:30 +0100 Remote-MTA: dns; mail.rackland.de Diagnostic-Code: SMTP; 501 5.1.3 Bad recipient address syntax

--1583364510.802252.20066 Content-Type: message/rfc822

Received: (nullmailer pid 20062 invoked by uid 8); Wed, 04 Mar 2020 23:28:30 -0000 From: Message Delivery Subsystem [email protected] To: <#@[]> Subject: Returned mail: Could not send message Date: Thu, 05 Mar 2020 00:28:30 +0100 Message-Id: [email protected] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1583364510.445574.20063"

--1583364510.802252.20066--

[hadmut]

seems as if nullmailer is playing ping-pong between different error messages.

That's definitely a harmful problem.

[hadmut]

BTW. , I see lots of error message (and probably a reason for the loop) that the receiving postfix mail node rejects messages because of

From: <#@[]> to: [email protected] smtp: Failed: 501 5.1.7 Bad sender address syntax

If the sender or recipient address are syntactically wrong for whatever reason, nullmailer should not try to send it, thus generating useless error messages and useless connection attempts. I'm not sure where this address comes from.

[xoxys]

@bruceg Any update on this. We are running into this as well.

[StefanKaifer74]

@bruceg We have the same problem, too!

[paurkedal]

Has anyone seen this with nullmailer 2.2? We've encountered the issue on Ubuntu 18.04 but not (yet, at least) on Ubuntu 20.04. So, I am wondering if 9186c42260a65c4d134fde5a65adc121e84dabfb solved the issue. (Though, #@[] is still generated for double bounces in src/dsn.cc and I can't see any place in the code which where this placement address is handled.)

[StefanKaifer74]

Has anyone seen this with nullmailer 2.2? We've encountered the issue on Ubuntu 18.04 but not (yet, at least) on Ubuntu 20.04. So, I am wondering if 9186c42 solved the issue. (Though, #@[] is still generated for double bounces in src/dsn.cc and I can't see any place in the code which where this placement address is handled.)

Sorry, you've right: I have the problem on Ubuntu 18.04.

[paurkedal]

That's a good thing, thanks for confirming. I am hoping we can continue using nullmailer on Ubuntu 20.04 hosts.