nullmailer: simple send-only mail transport agent

June 28th, 2009 edited by Tincho

Article submitted by JP Vossen. DebADay needs you more than ever! Please submit good articles about software you like!

Nullmailer is a minimal MTA (Mail Transport Agent) that provides mail delivery services to programs (cron jobs, system integrity checkers, log inspectors, etc.) in a host that otherwise does not require a full MTA like Exim or Postfix. Do not confuse an MTA with programs like Evolution or Thunderbird which are MUAs (Mail User Agent): programs that offer an interface to a human to write email.

Nullmailer is one of those packages that create a “well duh” moment when you find out about it. Normally, hosts with no MTA can’t send mail, which turns out to be a Bad Thing in terms of finding out when things like cron jobs break, or for monitoring logs or files. So you go and install a minimal system, then wonder why it’s being so quiet. Well, no MTA, no email. But Exim, Postfix or another full MTA is overkill and might be tedious to maintain. What you really need is just a basic MTA to send messages to the real mail server.

That’s nullmailer.

The package will prompt for your remote mail server and create /etc/nullmailer/remotes, where you can also specify authentication details. You probably also want to create /etc/nullmailer/adminaddr to receive in one mail account all mail destined to your local host. Each file is a oneliner that contains pretty much what you’d expect:

$ cat /etc/nullmailer/adminaddr

$ cat /etc/nullmailer/remotes

There are also several other files that may be used by nullmailer: /etc/nullmailer/defaultdomain and /etc/nullmailer/defaulthost in case you don’t already have /etc/mailname. For a complete list of control files, see the nullmailer(7) man page. Detailed information can be found in the man pages for each part of nullmailer: nullmailer-queue(8), nullmailer-inject(1), and nullmailer-send(8).


  • Simple.
  • Just Works.
  • Avoids the configuration, maintenance, memory footprint, and larger attack surface of a full MTA.


  • Configuration is scattered about in multiple one-line files instead of just a trivial config file.
  • Documentation is a also bit scattered.
  • The package might be a little more helpful by asking more questions when it’s installed (e.g. prompting for root’s mail recipient).
  • Doesn’t provide the -bs switch, so it’s not LSB compatible.
  • Gets very chatty in your log files when it can’t connect to the remote mail server.

Other alternatives:

Nullmailer has been available in Debian at least since Etch, and in Ubuntu Universe since Dapper.

Posted in Debian, Ubuntu |

5 Responses

  1. Mathijs Says:


    I’m using nullmailer too, but I want to add a big warning.

    When nullmailer can’t send a message because it’s rejected by the server(invalid address/attachment too big) it will keep on retrying every minute. Most mailers have failure/retry settings to say “try again in 5min, then 5hours, then 5days, then drop”.

    So you either must configure the “real” mail server to accept _everything_ from nullmailer, or run a cronjob that removes stuff older than x minutes from the queue-directory.

    I learned this the hard way.
    I sent an email with an attachment that was too big. I instantly got the message “size exceeded” so I thought of another way to transfer the data.
    What I didn’t know was that nullmailer kept it in its queue and kept retrying to send the (30mb) file every minute!
    Until I noticed traffic peaks on our outgoing gateway (logwatch on there stated an average 3Mbit outgoing in a weekend while the office was closed). In total it has been running for 4 days before I noticed.

    So just make sure to only use nullmailer for sending log files (automated system stuff) and not for user-generated mail or you will bump into this sooner or later. You can use it for websites (contact forms and stuff) too, but if you send email-verification messages (for people to activate their accounts), make sure your application checks for validity of the email-address, not just the format, or it will keep on retrying forever.


  2. Aristotle Pagaltzis Says:

    I suggest looking at instead. It has better support for SMTP AUTH, can handle multiple upstream smarthosts depending on “From:”, can use an MDA like procmail to deliver mail between local users, and all this can be configured separately by each user on the machine. I have yet to find a better minimal MTA.

  3. fool Says:

    Is there a similar MTA that just logs to syslog or some other log file? That’s what a minimal MTA for support of cron etc. should really just do for a user desktop or laptop. Combine that with a dbus notification on critical events that come through syslog or other log files.

  4. me Says:

    > The package might be a little more helpful by asking more questions when it’s installed (e.g. prompting for root’s mail recipient).

    it does, depending on your debconf priority. dpkg-reconfigure nullmailer asks these questions if the priority was too low at install time.

  5. _phred Says:

    Thanks for the writeup. I’m using nullmailer for a Xen server cluster — one Xen dom0 host running several domU’s that need to be able to send mail to the outside world, but don’t need to run a full-blown MTA. Nullmailer fits this niche and has the advantage over ssmtp and msmtp because it queues messages and sends them asynchronously.

    I have it set now so that nullmailer drops mail from each server onto my one “big” mail server which runs Postfix. This way, I can have a single DNS entry and centralize SPF, DomainKeys, delivery retry, logging, etc.

    The behavior that Mathjis described is actually desired on my servers, as I want to make sure that every message gets delivered to the mailer and run through Postfix. It’d be nasty, though on a desktop or laptop, so I completely agree with his assessment.

    Oh, and for Debian people, it’s as easy as:
    apt-get install nullmailer
    And, since you won’t need it anymore:
    aptitude purge exim4