I would like to suggest reopening this innocent looking bug report :) ...and configure nullmailer with a default of not connecting to anything. Instead, it should simply discard mails. That is much more sane and to be expected from a fresh installation.
Guessing a remote mail server on a workstation (99% of all Ubuntu installations?) is not the way forward, and since nullmailer does NOT have a way of detecting permanent connection errors, it will just continue filling up /var/spool/nullmailer/queue and /var/log/mail.err*. And since the root user does not necessarily map to the correct user account and null mailer may not know who to send emails to, anyways, the whole idea of guessing a remote relay is terrible. For instance, after a couple of upgrades, I somehow had php looking for a dynamic library that did not exist. This ended up at 1.5 GB of mail queue and mail.err logs and probably millions of failed DNS lookups. I think it's pretty severe to have a default configuration run amok like that. I have been flooding DNS servers for months because of this. For the record, I did once empty /etc/nullmailer/remotes and now "mail." is back, presumably after an update. Upstream bug: https://github.com/bruceg/nullmailer/issues/1 Google search reveals that the issue is quite common and has cause severe troubles for many. I can only imagine that this is costing loads of traffic and disk space... https://encrypted.google.com/search?hl=en&q=nullmailer%20smtp%20error -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/497151 Title: /etc/nullmailer/remotes file contains string "mail." by default causing incessant DNS requests that fail. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nullmailer/+bug/497151/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
