Configure Exim to forward email

Question

I have an Ubuntu 10.04 VPS set up to manage sub.example.com and I've configured Exim to send email using this tutorial from the Linode Library. That's working, but in addition to sending email I realized I need a single non-root email address ([email protected]) to forward to me ([email protected]).

I've read the Exim documentation on this [1] and I don't really get what I'm supposed to do (it seems to expect that readers already know what files to change and what certain directives do). There's also a similar question here from '09 and I can't tell which (if any) of the solutions there would apply to my case or what files need to be modified with the suggested lines.

TBH, I'd be just as happy if there is a very simple way to do this without Exim that wouldn't conflict with sending email through Exim the way I already have it set up. I have already tried modifying /etc/aliases to no avail.

You can probably tell I'm pretty new to configuring MTAs... thanks in advance.

[1] Which I apparently can't link to, since this is my first post on ServerFault. I believe the relevant section is Chapter 22 - The redirect router.

Solution

In the explanation that follows, I am assuming that you followed the instructions in the URL you mentioned and you have selected "internet server". I also assume that "localhost" is one of the valid domain names that your exim is configured to recognize as a local domain.

First, the format of what you put in /etc/aliases should have been:

admin: [email protected]

You don't need to run newaliases on an exim system, it's just provided as a compatibility layer for applications expecting a more "sendmail-like" environment. Exim directly scans the contents of the /etc/aliases file the first time it reads it and caches results, remembering it for subsequent lookups if there are any. It doesn't actually use the /etc/aliases.db file like sendmail does.

When you edit /etc/aliases, you can test how an address will be handled from the commandline. In this first example, my system is not configured to handle the admin alias. It complains that it doesn't know how to handle this address by describing it as undeliverable:

[todd@tlyons /etc/exim4]$ grep admin /etc/aliases
[todd@tlyons /etc/exim4]$ exim -bt admin@localhost
R: system_aliases for admin@localhost
admin@localhost is undeliverable

In the second example, my system is properly configured to handle the admin alias. Explanation follows the example:

[todd@tlyons /etc/exim4]$ grep admin /etc/aliases
admin: [email protected]
[todd@tlyons /etc/exim4]$ exim -bt admin@localhost
R: system_aliases for admin@localhost
R: dnslookup for [email protected]
[email protected]
    <-- admin@localhost
  router = dnslookup, transport = remote_smtp
  host gmail-smtp-in-v4v6.l.google.com [2001:4860:b007::1a] MX=5
  host gmail-smtp-in.l.google.com      [173.194.79.27]      MX=5
  host gmail-smtp-in-v4v6.l.google.com [209.85.225.27]      MX=5
  host alt2.gmail-smtp-in.l.google.com [74.125.45.27]       MX=20
  host alt3.gmail-smtp-in.l.google.com [173.194.66.27]      MX=30
  host alt4.gmail-smtp-in.l.google.com [173.194.65.27]      MX=40

The first R: line is a debugging output line that says it was processing the email address with the "system_aliases" router. It doesn't come out and say it directly, but it did find "admin" in the system_aliases router and "expanded" that to "[email protected]". Once exim expands an address to something else (or multiple somethings), it reruns each address through the routers, looking for a match. In the example above, it ran the [email protected] address through the routers and the "dnslookup" router matched. That means it determined it needed to use SMTP to send it out to a remote mail server. Part of that is looking up the MX records of gmail.com, which it did and displayed for you to see how it would try to deliver that mail.

So to answer your original question, it's likely that you just entered the data in your /etc/aliases incorrectly. The left hand side is just the local part (ie the "user" in [email protected]), followed by a colon (:), followed by spaces or tabs, followed by the email address (or email addresses joined by commas) to deliver it to. You cannot put the complete email address as the left hand side (before the colon).

Comments

[mgorven]

What did you try in /etc/aliases? Did you run newaliases after editing it?

[IceCreamYou]

I had admin: root,[email protected] and did not run newaliases after editing.

[IceCreamYou]

Awesome, thanks for the thorough explanation. I had /etc/aliases set up as you suggested (previously it said admin: root,[email protected] and I removed the "root," after reading this just to make sure I was doing exactly what you suggested). I can now send email to [email protected] from [email protected] with the command echo "test" | mail -s Test [email protected] but when I send an email to [email protected] from a non-example.com domain (e.g. [email protected]) it disappears into the ether with no "not delivered" response or anything. Any thoughts?

[Todd Lyons]

You stated that you are sending email from "[email protected]", do you mean that you are actually trying to send email from Gmail to your domain? One of the questions asked during the dpkg reconfigure was what IP addresses your mail server should listen on, and it defaults to the loopback only. Thus far, you have obfuscated all domain names and IP addresses to the point that we don't know for sure whether you actually have a public IP address or if you are behind a NAT router. Without more detail, we cannot troubleshoot your system from the outside.

[IceCreamYou]

The server has a unique IP address. The exact situation here is I'm trying to set up an SSL certificate and the seller will only send the CRT to a predefined set of email addresses. But I see what you're saying about the listening IP -- I guess I'll need to rethink this a little.