This short tutorial shows how to configure a Ubuntu 14.04 Cloud server to forward system-generated mails sent to the root account to your email address.
Why would you want to forward mails sent to root to an email address?
Because most properly-configured Cloud servers are managed using a (normal) user account with sudo (root) privileges. So unless you switch to root while logged in as a normal user, and then type the mail command, you will not see those emails.
Here, for example, is the output of the mail command after switching to root on one of my servers:
"/var/mail/root": 18 messages 18 new >N 1 zoo@this.li Tue Dec 31 05:36 14/695 *** SECURITY information for methisyou *** N 2 Cron Daemon Sun Jan 5 06:37 22/1081 Crontest -x /usr/sbin/anacron || ( cd / && run-parts --r N 3 Cron Daemon Sun Jan 12 06:31 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 4 Cron Daemon Sun Jan 19 06:34 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 5 Cron Daemon Mon Jan 27 06:39 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 6 Cron Daemon Sun Feb 2 06:51 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 7 zoo@this.li Mon Mar 10 02:46 14/650 *** SECURITY information for methisyou *** N 8 Cron Daemon Sat Mar 15 06:38 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 9 Cron Daemon Mon Mar 17 06:49 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 10 Cron Daemon Sun Mar 23 06:37 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 11 Cron Daemon Sun Mar 30 06:35 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 12 Cron Daemon Sun Apr 6 06:25 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 13 Cron Daemon Sun Apr 13 06:45 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 14 zooq@this.li Wed Jun 11 13:48 14/641 *** SECURITY information for methisyou *** N 15 Cron Daemon Thu Jun 12 06:44 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 16 Cron Daemon Sun Nov 16 06:47 24/991 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 17 Cron Daemon Sun Nov 30 06:46 22/1081 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r N 18 Cron Daemon Sun Nov 30 06:47 24/991 Cron test -x /usr/sbin/anacron || ( cd / && run-parts --r ?
That’s a lot of unread messages. Some of those messages might contain important information about the server, some of which could be the result of cron jobs or from system alerts triggered by unauthorized user activity. For example, here’s the content of one of those emails sent to the root account after an unauthorized (and failed) user activity:
methisyou : Jun 11 13:48:29 : zoo : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/zoo ; USER=root ; COMMAND=/usr/bin/apt-get update
That’s an alert you won’t see if you don’t read emails sent to root. So this tutorial will show you how to configure the server to make it easy for you to read such emails – by sending them to your email address. This tutorial assumes, of course, that you have access to and manage a Cloud server running Ubuntu 14.04.
To forward roots mail to an email address, open the /etc/aliases file with your favorite text editor. The default content should read:
# See man 5 aliases for format postmaster: root
Edit it so that it reads:
# See man 5 aliases for format postmaster: root root: user@methisyou.net
That will forward all system-generated emails sent to root to the specified email address. Replace user@methisyou.net with your real email address. Save and close the file, then run the newaliases command to effect the change.
That’s it. If you don’t receive the expected emails, check you Spam folder.
Nice tip, though you may want to specify:
The server needs to not be behind a NAT/router, or the remote MDA will not accept it : your box will introduce itself with “EHLO methisyou” but the MDA’s reverse lookup will detect you are “actually” “public.ip.number” (your public IP)
Do you know of a simple setup that solves this reverse-lookup barrier – either by causing the sendmail MTA to declare itself as necessary, or by using another MTA that can still be used in bash scripts…? 🙂
[subscribe] oops 🙂
I hope you realize that a real domain was removed from that code block. The only real issue you have to worry about is if the receiving end starts marking your emails as spam. I’ve never had that happen, but that’s the kind of problem that SPF, DKIM and OpenDMARC are designed to solve.
I know that if this fictional methisyou.net is considered public in this example – however I was wondering if there was an easy way to allow this to work in the general use case (id est, NAT notwithstanding) with the standard sendmail
I am referring specifically to a use case of the server you are managing/monitoring being behind a NAT which is trying to directly access the MDA of something like a gmail.com mail address. In such a setup, managed-server tries to connect to (say Google’s) MDA saying “EHLO managed-server” ; Google then traces back your IP with DNS reverse lookup to find that you’re showing as some 39.40.41.42 which does not resolve to “managed-server” and rejects the message altogether…
No, I’ve not considered that particular use case, but if your server is sitting behind a router and the router’s public IP is also your server’s, wouldn’t the process of establishing an RDNS record follow the standard process of setting up such a record?
Also, isn’t RDNS just one reason why emails coming from a particular box/domain might be rejected? If the RDNS test fails, but the emails are signed using DKIM, there’s a very strong chance that the receiving server will not mark them as spam. That makes it look/sound as if RDNS and protocols like DKIM are totally, completely different things, but in reality, doesn’t DKIM accomplish the same thing as RDNS?
For the record, I’ve been forwarding these emails to a GMail, Yahoo, Vivaldi.net and Fastmail accounts without ever establishing an RDNS record or even using SPF or DKIM and they’ve always been accepted. The only time Google’s SMTP server rejected my emails was when the From address was not a real email address.