-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nullmailer crashing machines with endless loops #69
Comments
That is odd. The What version are you running? Did you happen to keep the queue file for one of the looping messages? |
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); --1577655060.650142.10875 This is the nullmailer delivery system. The message attached below --1577655060.650142.10875 Reporting-MTA: x-local-hostname; speedy.fritz.box Final-Recipient: rfc822; [email protected] --1577655060.650142.10875 Received: (nullmailer pid 10871 invoked by uid 8); --1577655060.650142.10875-- |
I just again had a 3.5 G spool directory full of nullmailer endless loop messages like #@[] Received: (nullmailer pid 20085 invoked by uid 8); --1583364512.765404.20086 This is the nullmailer delivery system. The message attached below
--1583364512.765404.20086 Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Final-Recipient: rfc822; #@[] --1583364512.765404.20086 Received: (nullmailer pid 20082 invoked by uid 8); --1583364512.765404.20086-- #@[] Received: (nullmailer pid 20062 invoked by uid 8); --1583364510.445574.20063 This is the nullmailer delivery system. The message attached below --1583364510.445574.20063 Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Final-Recipient: rfc822; [email protected] --1583364510.445574.20063 Received: (nullmailer pid 20059 invoked by uid 8); --1583364510.445574.20063-- |
#@[] Received: (nullmailer pid 20065 invoked by uid 8); --1583364510.802252.20066 This is the nullmailer delivery system. The message attached below
--1583364510.802252.20066 Reporting-MTA: x-local-hostname; waschbrett.home.danisch.de Final-Recipient: rfc822; #@[] --1583364510.802252.20066 Received: (nullmailer pid 20062 invoked by uid 8); --1583364510.802252.20066-- |
seems as if nullmailer is playing ping-pong between different error messages. That's definitely a harmful problem. |
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] 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. |
@bruceg Any update on this. We are running into this as well. |
@bruceg We have the same problem, too! |
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, |
Sorry, you've right: I have the problem on Ubuntu 18.04. |
That's a good thing, thanks for confirming. I am hoping we can continue using nullmailer on Ubuntu 20.04 hosts. |
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.
The text was updated successfully, but these errors were encountered: