Ubuntu
nullmailer package

Nullmailer creates loop by attempting to send mail to #@<>

Asked by William Edwards

We have a few machines that regularly fill up /var/spool/nullmailer/failed/. The 'To' address for the emails filling up /var/spool/nullmailer/failed/ is '#@<>' (without ''). I feel like this is the result of some kind of failed variable substitution, where '#' is supposed to be the local part and '<>' is supposed to be the domain. Is this a result of sending mail to an empty address perhaps?

Either way, /var/spool/nullmailer/failed/ fills up and the disk runs out of inodes, seemingly because of infinite retries by Nullmailer.

In a mailing list somewhere, I read '#@<>' is a 'special address', without any further explanation of why it'd be a special address. The ##postfix and ##exim folks don't know either.

Has anyone seen the same behaviour?

Nullmailer version: 2.1-7

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu nullmailer Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

What is the output of:

lsb_release -a; uname -a; apt-cache policy nullmailer

Thanks

Revision history for this message
William Edwards (tuxiswilliam) said : 		#2

```
root@http1:~# lsb_release -a; uname -a; apt-cache policy nullmailer
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch
Linux http1 4.19.0-0.bpo.6-amd64 #1 SMP Debian 4.19.67-2+deb10u1~bpo9+1 (2019-09-30) x86_64 GNU/Linux
nullmailer:
  Installed: 1:2.1-7~bpo9+1
  Candidate: 1:2.1-7~bpo9+1
  Version table:
 *** 1:2.1-7~bpo9+1 100
        100 http://ftp.debian.org/debian stretch-backports/main amd64 Packages
        100 http://debmirror.tuxis.nl/debian stretch-backports/main amd64 Packages
        100 /var/lib/dpkg/status
     1:1.13-1.2 500
        500 http://debmirror.tuxis.nl/debian stretch/main amd64 Packages
```

Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#3

You are using Debian. This is Ubuntu support only. Your distribution is not supported here and has it's own community and support forum here:
http://forums.debian.net/

I suggest you post on there for support for Debian.

Thanks

Revision history for this message
Sebastian Forsman (sforsman) said : 		#4

Greetings,

our company has actually encountered this same behavior on several occasions. We are using Ubuntu. The problem seems to arise when there is a problem connecting to the SMTP relay (defined at /etc/nullmailer/remotes).

Here's the requested output from one of the servers related to the latest incident:

> lsb_release -a; uname -a; apt-cache policy nullmailer

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
Linux xxx 5.3.0-1019-aws #21~18.04.1-Ubuntu SMP Mon May 11 12:33:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
nullmailer:
  Installed: 1:2.1-5
  Candidate: 1:2.1-5
  Version table:
 *** 1:2.1-5 500
        500 http://xxx.clouds.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Firen (f1ren) said : 		#5

Same issue on our Ubuntu servers:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
Linux websiteqa 4.15.0-106-generic #107-Ubuntu SMP Thu Jun 4 11:27:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
nullmailer:
  Installed: 1:2.1-5
  Candidate: 1:2.1-5
  Version table:
 *** 1:2.1-5 500
        500 http://nl.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status

For some reason the nullmailer wants to send out an email to #@[] which isn't accepted by our mailserver which generates a bounce and from there the bounce keeps being retried for delivery.

Deleting /var/spool/nullmailer/queue and re-creating it resolved the bounce

Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#6

If you grep for "#@" recursively through /etc does it come up with anything?

Revision history for this message
Firen (f1ren) said : 		#7

No hits.. I found a workaround that works for me though:
I created /usr/lib/nullmailer smtpfix with the following content: https://raw.githubusercontent.com/alfsb/nullmailer-smtpfix/master/smtpfix

And in /etc/nullmailer/remotes/ I've replaced smtp with smtpfix. After running nullmailer-send the repeating bounce e-mail that can't be delivered is discarded.

Can you help with this problem?

Provide an answer of your own, or ask William Edwards for more information if necessary.

To post a message you must log in.