Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 (admin@sub.example.com) to forward to me (me@gmail.com).

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.

share|improve this question
    
What did you try in /etc/aliases? Did you run newaliases after editing it? –  mgorven Jun 7 '12 at 3:46
    
I had admin: root,me@gmail.com and did not run newaliases after editing. –  Icemonster Jun 7 '12 at 18:28

1 Answer 1

up vote 4 down vote accepted

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: me@gmail.com

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: me@gmail.com
[todd@tlyons /etc/exim4]$ exim -bt admin@localhost
R: system_aliases for admin@localhost
R: dnslookup for me@gmail.com
me@gmail.com
    <-- 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 "me@gmail.com". 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 me@gmail.com 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 user@domain.com), 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).

share|improve this answer
    
Awesome, thanks for the thorough explanation. I had /etc/aliases set up as you suggested (previously it said admin: root,me@gmail.com 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 admin@sub.example.com from root@sub.example.com with the command echo "test" | mail -s Test admin@sub.example.com but when I send an email to admin@sub.example.com from a non-example.com domain (e.g. another@gmail.com) it disappears into the ether with no "not delivered" response or anything. Any thoughts? –  Icemonster Jun 7 '12 at 18:47
    
You stated that you are sending email from "another@gmail.com", 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. –  Todd Lyons Jun 7 '12 at 20:29
    
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. –  Icemonster Jun 7 '12 at 20:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.