BRUB menu Ubuntu 14.10

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:

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:

Related Post:  How to customize Cinnamon 1.6

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.

Related Post:  The problem with Scaleway

To forward roots mail to an email address, open the /etc/aliases file with your favorite text editor. The default content should read:

Edit it so that it reads:

That will forward all system-generated emails sent to root to the specified email address. Replace 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.


Share on facebook
Share on twitter
Share on pinterest
Share on linkedin

Hola! Did you notice that no longer runs network ads?  Yep, no more ads from the usual suspects that track you across the Internet.  But since  I still need to pay to keep the site running, feel free to make a small donation by PayPal.

Subscribe for updates. Trust me, no spam!

Mailchimp Signup Form

Sponsored links

1. Attend Algorithm Conference, a top AI and ML event for 2020.
2. Reasons to use control panel for your server.
3. DHgate Computers Electronics, Cell Phones & more.

5 Responses

  1. 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…? 🙂

    1. 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.

      1. I know that if this fictional 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 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 which does not resolve to “managed-server” and rejects the message altogether…

        1. 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, 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the latest

On social media
Via my newsletter
Mailchimp Signup Form

Sponsored links

1. Attend Algorithm Conference, a top AI and ML event for 2020.
2. Reasons to use control panel for your server.
3. DHgate Computers Electronics, Cell Phones & more.
Hacking, pentesting distributions

Linux Distributions for Hacking

Experts use these Linux distributions for hacking, digital forensics, and pentesting.


The authors of these books are confirmed to speak during

Algorithm Conference

T-minus AI

Author was the first chairperson of AI for the U.S. Air Force.

The case for killer robots

Author is the Director of the Center for Natural and Artificial Intelligence.

Why greatness cannot be planned

Author works on AI safety as a Senior Research Scientist at Uber AI Labs.

Anastasia Marchenkova

An invitation from Anastasia Marchenkova

Hya, after stints as a quantum researcher at Georgia Tech Quantum Optics & Quantum Telecom Lab, and the University of Maryland Joint Quantum Institute, I’m now working on superconducting qubit quantum processors at Bleximo. I’ll be speaking during Algorithm Conference in Austin, Texas, July 16 – 18, 2020. Meet me there and let’s chat about progress and hype in quantum computing.