In the last post in my Postfix series we went through the basics of configuring Postfix to accept mail. This second part will be a somewhat short addendum in which we cover a few extra settings related to how Postfix finds the right user to deliver mail to. Then in the third post we will finally move on to receiving real mail (as opposed to telnet fakery).
Postfix has an impressive amount of settings that can manipulate where email ends up. I’m only going to cover two and then quickly list some of the others.
In the last part, one of the four initial configuration parameters was
myorigin but we never actually made use of it. It’s not going to be massively useful going forward but I think it’s helpful in understanding the sort of system, that we’re dealing with.
Start up a telnet sessions as before, i.e.
telnet localhost 25
Greet Postfix with a HELO [name of machine we’re calling from] and enter the
MAIL FROM and
RCPT TO commands as follows only substituting real user names on your system for
MAIL FROM:<alice> 250 2.1.0 Ok RCPT TO:<bob> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> This is an email without domains in the from or to fields. . 250 2.0.0 Ok: queued as 4B3A6D4091B QUIT 221 2.0.0 Bye Connection closed by foreign host.
The point is that we’re not assigning domain names to the usernames. It’s just
bob. Postfix will see to it that each is assigned whatever domain name we have set in
myorigin, in our case the value of
$mydomain, and so it delivers the mail to itself, seeing as it is the final destination for mails headed to
It’s a neat trick if you are hosting an email system where most or a lot of email is in-house. But that’s not where we are headed so why bother with this? The point to understand is that although our setup is local, it isn’t local in the sense that Postfix automatically understands that a username without a domain name is a local user. We first need to assign a domain name to the domain-less user (using the
myorigin setting), then realize that that domain is here, and then deliver the mail to a local user.
Aliases are well, aliases. Mail addressed to an alias will be delivered to the user who has that alias listed in an alias file. This can be useful for a number of scenarios. Say you want to confirm that you are the legitimate owner of a domain name, you will often be required to certify that you are in control of the postmaster@[domain name] account. If you don’t want to have a permanent user named ‘postmaster’, a quick ‘postmaster’ alias for your standard user is an effective way to achieve that. Or if you need a throwaway email address to create an account on a web site, a quickly created (and equally quickly deleted) alias will suffice.
A final benefit of aliases is that they provide a superior way of filtering and sorting email. With webmail and the like your only options for sorting and filtering are a) using multiple accounts or b) filtering by sender. With aliases you get the best of both: a single account/login and the ability to supply different addresses for different purposes. So you tell facebook, twitter etc. that your address is firstname.lastname@example.org, alias the address to your main account and now you can filter by a single recipient rather than a long list of senders.
Let’s try the postmaster trick. There are two alias settings in main.cf:
alias_database. It seems that the former is a complete listing of all the alias databases Postfix should check. The latter then is a subset of the former: The databases that Postfix needs to ‘rebuild’ whenever new aliases are added. This rebuilding takes the form af creating a file with the same name as the source, only with a .db suffix. What this means for you, the user, is that if you use a simple textfile to maintain your list of aliases, this file should be listed in
alias_maps and again in
alias_database. It would be preferable to not have any kind of databases at all in order to keep things as simple as possible but sadly, aliases do require a database to work. Whenever you use databases you tell Postfix what type it is in the format [type]:[database] where database can be a file, a MySQL table etc. depending on type. We shall stick with the default, ‘hash’. The database file is listed without the ‘.db’ suffix:
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
When you edit the
/etc/aliases file you will in all likellihood already find a setting for postmaster (usually to root). If you stick with this, you will not see any mail for postmaster. Postfix assumes the identity of the user to which it is delivering mail (check the ownership of the mail files in
/var/mail to see this) but it will not do so for root for safety reasons. Imagine I found a way to make Postfix run a script that I sent in an email and then imagine that I wrote root, saying ‘rm -rf /’. So we set postmaster to be an alias for our standard username:
# See man 5 aliases for format postmaster: alice
Now that we have added new aliases, we need to rebuild the aliases database. We do this simply by running the command
newaliases. If you want to, you can check that the
/etc/aliases.db file get’s updated.
Now we use telnet to send an email to postmaster. You can use the full name with domain or you can just use the
myorigin auto-completion trick. Here’s the effect as seen in the log: An email addressed to postmaster gets delivered to
Oct 18 16:23:33 THEMINT postfix/local: 09849D44799: to=<alice@THEMINT>, orig_to=<postmaster@THEMINT>, relay=local, delay=1.4, delays=0.4/0/0/1, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
You should of course check and
cat /var/mail/alice to see that your mail has arrived.
Forward files are a very simple way of changing where mail ends up. In all it’s simple glory it’s a text file called
.forward in a system user’s home directory. Any local mail addressed to the user is forwarded to the local/virtual address in the text file. This makes for a very easy way to forward system notices from root to say, a virtual email address that we are more likely to see in the course of the day:
[~] cat .forward email@example.com
Of course, for this to work we have to have a working relay, i.e. a way to pass on email, from our local machine (which we may or may not have at the moment), a topic for later posts.
Other rewrite settings
There are far more ways to rewrite addresses in Postfix than is likely to be useful for a home setup. Just for good measure I will run through a few of them:
- Listed in the
canonical_mapssetting are a special sort of aliases where one sort of address is used internally, say a shortened form, and another is used externally, say the complete name spelled out with periods in between names.
- ‘Masquerading’ refers to hiding specific hostnames from the address, so that your email address isn’t firstname.lastname@example.org but just email@example.com.
- ‘Relocated’ users are another form of aliases but instead of silently redirecting the mail, it is rejected with information about the new address.
- Finally Postfix has settings that can be used to catch mail to unknown users (instead of the default behaviour which is to reject it outright)
You may or may not be familiar with some of these tricks from a corporate or other workplace setting. I’m not going to use or detail any of these as they mostly will not be relevant to the standard home setup. But it’s good to know roughly what they mean if you see settings related to them.
So now we have a basic system where email recipients still correspond to local users but with a few twists and options to redirect mail. It’s not much but it works. The next step is to make our SMTP server accessible from the outside. Keep in mind though, that changing the hostname from an internal one (in my case “THEMINT”) to one that makes sense on the internet (“brokkr.net”) will not change that it is a local system in the Postfix sense that all addressees (except aliases and the like) must be shell accounts.