Web Servers and Email: Postfix on Ubuntu

Posted Saturday 11th April, 2009

Setting up web servers is an oft-covered subject in the web development blogosphere. However, when I needed to set up a shared web and email server, I discovered that such documentation was somewhat more dispersed. With that in mind, and following the development of an email newsletter at work (in which I demonstrated several email testing techniques that were of interest to some of the other developers), I began drafting a blog post that would hopefully bring some of that information together. Sadly, I never finished.

Due to an ever more stressful workplace and the arrival of another child in the household, I took a somewhat forced break from blogging. This was entirely unintended and I’ve decided to get back on the wagon again by finishing the aforementioned post.

So here it is; the finished article on setting up Postfix on a shared mail and web server. Please remember that I’m technically a mail server numpty and probably won’t have all the answers to questions should you have them. However, feel free to leave them in the comments and hopefully someone out there (or someone I can poke for comment elsewhere) can help you out.

A bit of background

I made the jump from supported, pre-built hosting to entirely self-managed hosting last year. As a result, I soon discovered the need to handle email received by the various hosted domains on my server.

One solution to this problem would be to use Google Apps for Business. Too easy, drill sergeant; and also $50 more than I was willing to spend a year. Another solution would be to install my own email server and manage it myself. Despite this idea giving me The Fear™, it also meant I’d be learning something new – a buzz I find difficult to ignore at the best of times.

Given those options, I’m sure it’s not too hard to figure out which route I took, and the following blog post is a small amount of what I learnt in the process.


Often, when building a web server, the server hostname is overlooked as unimportant. This is generally because the DNS system provides all the functionality needed when serving files over HTTP. However, when the server is required to handle email, it is important to set a hostname because it is used by the various email protocols as a source and destination identifier; ergo a key component in the identification of spam.

Postfix will let you send and receive mail just fine between accounts on a machine with a fantasy name. However, you cannot use a fantasy hostname in your email address when sending email via the Internet, because no-one would be able to reply to your mail. In fact, more and more sites refuse mail addresses with non-existent domain names.

Further to this, you may want to specify a fully-qualified domain name hostname. A hostname is considered to be a fully qualified domain name (FQDN) if all the labels up to and including the top-level domain name (TLD) are specified. The hostname “mail.nerfabulousdesigns.co.uk” terminates with the top-level domain “co.uk” and is thus fully-qualified. Depending on the system, an unqualified hostname such as “server1” or “test-server” may be combined with default domain names in order to determine the fully qualified domain name. However, in most cases, a web server or mail server won’t be running in that sort of environment.

With all that in mind, it’s best to use a domain name you can access the DNS records for, as you’ll want to forward email to it using the MX record. An accepted standard, when working with mail, is to use “mail.mydomain.com”, however, in this case, we’re sharing email and web serving duties on the same box. A better solution would be to come up with any name that you can use to uniquely identify the server in your DNS settings. For the purpose of my examples, I’m going to work with the hostname “spartacus.nerfabulousdesigns.co.uk”.

DNS for your hostname

Before I start wading into the installing and configuring the server, it’s important to get the DNS set up in your DNS manager. So, if the IP address of our server is 123.456.789.123 we’ll want the following DNS records:

A Records:
spartacus.nerfabulousdesigns.co.uk -> 123.456.789.123
mail.nerfabulousdesigns.co.uk -> 123.456.789.123

MX Record:

Any other domains you want to set up for email only need the following rules:

A Records:
mail.yourdomain.com -> 123.456.789.123

MX Record:

Once you’ve saved those changes, and you’re awaiting DNS propagation, it’s time to get back to our server.

Server settings for your hostname

To find out the current hostname of your server (which is defined during installation), type the following:

$ hostname

The hostname command will output the current hostname if you run it without any parameters. If you want to see the fully qualified hostname, type the following:

$ hostname -f

To change your hostname temporarily, you can simply enter the new hostname as the first parameter of the hostname command. So, assuming I want to identify my server as “spartacus”, I’d enter the following:

$ hostname spartacus.nerfabulousdesigns.co.uk

Now we can check our change:

$ hostname


Unfortunately, that change will be reset should the machine be rebooted for any reason.


To make the change permanent, you’ll need to edit the single-line /etc/hostname file:

$ sudo vim /etc/hostname

Update it to contain the following:


Now you can trigger your change by restarting the hostname daemon:

$ /etc/init.d/hostname.sh start

However, you don’t need to do that just yet since you’ll probably want to restart your server later on in the process.

The hosts file

Next we’ll need to update the hosts file on the server so that it recognises the new hostname as a referer to the loopback IP To do that, edit the hosts file with the following command:

$ sudo vi /etc/hosts

And then update it so that it contains a line similar to this:        spartacus.nerfabulousdesigns.co.uk

Once this file has been saved, we can do that reboot we were going to do earlier:

$ sudo reboot

Once your server is back up, the hostname change is complete. Your server will now use the loopback address when hostname references are used, instead of wasting valuable time checking DNS records.

Install Postfix

Now that the server is primed for email, it’s time to install postfix – and while we’re at it, let’s install mailx, an improved version of the mail email user agent program, and let’s also confirm we have telnet installed as we’re going to use it for testing later on:

$ sudo aptitude install postfix mailx telnet

As Postfix installs, you’ll be asked a number of configuration questions:

For “general type of mail configuration”, choose:

Internet Site

You will then be asked the fully qualified domain name of your server, which in our case is:


Once you’ve done that, the installation is complete. Your web server is now capable of sending email; and to prove it, let’s just test it from the command line.


Let’s send an email to a real email address (remember to replace somebody@somewhere.com with the real email address of your choice):

$ mail somebody@somewhere.com

The mail program will now ask you for a subject. Once you press return, mail will now be accepting the body of your email (albeit without a prompt). To tell the program that you’ve reached the end of your email body, you’ll need to place a single full-stop character, “.”, on a line by itself (since the return character is perfectly valid in the body of your mail). Finally, the mail program will then ask you for any CC addresses.

Here’s an example of the complete screen output:

$ mail somebody@somewhere.com
Subject: Testing my all new email server!
Red leader, this is mail server. Are you receiving, over?

You won’t receive any confirmation that the email has been sent – you should just return to the command prompt – however, as long as everything was set up correctly, you should have received the email.

The next step is to configure our mail server so that it knows what to do with received email.


Configuration of a mail server is where all the pain and torment begins; but in this case, I only want to set up mail forwarding – which takes all the pain and torment away and leaves us with a fairly straight forward, unburdened mail server that’s using very little disk space. I could usually do this at the DNS level, but I chose not to in case I decided to work with real mail boxes in the future – and also because I was still relishing the learning experience. If you want to set up something different, I’m afraid you’re going to have to look elsewhere for a tutorial because I haven’t the time (or the patience) to go through the multitude of different set-ups that are possible.

The first step in setting up mail forwarding in Postfix is to create a virtual hash. To do that, we need to create the following file:

$ sudo vim /etc/postfix/virtual

And inside that file, we need to define some values. Here’s how we’d set up nerfabulousdesigns.co.uk as a mail forwarding domain:

john@nerfabulousdesigns.co.uk    john.smith@yahoo.com
joe@nerfabulousdesigns.co.uk     joe.bloggs@yahoo.com

# For a catch-all, do the following
@nerfabulousdesigns.co.uk        example@yahoo.com

Once you’ve saved that file, run the following command to create the postmap:

$ postmap /etc/postfix/virtual

Next you’ll also need to update this file:

$ sudo vim /etc/postfix/main.cf

Add your domain to virtual_alias_domains and your virtual hash to virtual_alias_maps like so:

virtual_alias_domains = nerfabulousdesigns.co.uk ...other hosted domains...
virtual_alias_maps = hash:/etc/postfix/virtual

Finally, you’ll need to do the following to restart Postfix:

$ postfix reload

Any emails to the domains or addresses you added to the virtual hash should now be forwarded as expected.


Finally, let’s test the email server is working using Telnet. This is a handy little technique for checking everything is as expected, since it will also display responses at every stage of the mail sending process.

You can telnet from any machine that has it installed – and since we installed it on our server earlier, we can even telnet the server to itself, which might be useful when trying to track down problems.

To begin with, let’s Telnet to our server over the default SMTP port 25:

$ telnet mail.nerfabulousdesigns.co.uk 25

Which should trigger a response similar to this:

Connected to mail.nerfabulousdesigns.co.uk.
Escape character is '^]'.
220 spartacus.nerfabulousdesigns.co.uk ESMTP Postfix (Ubuntu)

If the connection was a success, you should receive a 220 SMTP reply code. For more information, here’s a handy reference on SMTP reply codes.

The next thing we need to do, in the essence of being polite, is greet the mail server. We can do that one of two ways. We can either use the SMTP command, HELO:

HELO my.local.domain
250 spartacus.nerfabulousdesigns.co.uk

Or we can use the more recent EHLO command, which will return more detailed information about the server:

EHLO my.local.domain
… More detailed info. here…

Great, so now that we’ve identified ourselves, we’re reading to start defining the envelope for our message. First, we need to tell the mail server who the sender is:

250 2.1.0 Ok

Second, we need to tell the mail server who we’d like the email delivered to:

RCPT TO:joe@nerfabulousdesigns.co.uk
250 2.1.5 Ok

That’s it; the envelope is now complete. We can now move onto filling our message with data. To do that, we simply use the command DATA, which will then allow us to enter the subject and main content for our message:

354 End data with .
Subject: Test Email
This is a test email.
250 2.0.0 Ok: queued as 40F438D023

Our message is complete, and has been queued by the mail server for redistribution to the recipient. We’re done here, so let’s quite out of the telnet session:

221 2.0.0 Bye
Connection closed by foreign host.

And we’re now back at our original command prompt. If you check the mailbox of your recipient, you should have successfully received the email.


Despite the fact that I could probably have handled email in more efficient ways, I thoroughly enjoyed learning about Postfix and the black magic therein. I’m sure that some of my peers will have plenty to correct me on, and I sincerely hope they do; as previously stated, this was intended as a learning experience, and learning is what I have done.

Hopefully, some – if not all – the techniques used in this article will be of some use to you. Certainly, they have aided me in my understanding of core internet technologies.

Please feel free to comment, question, or to point out flaws with my methods. I hope the discussion is fruitful.

Included in: Development, Email, Linux, Server, UNIX, Web


  1. Accessibility
  2. Agile
  3. Ajax
  4. Apache
  5. API
  6. Architecture
  7. Books
  8. Browsers
  9. CMS
  10. CouchDB
  11. CSS
  12. Design
  13. Development
  14. Django
  15. Email
  16. Events
  17. Gaming
  18. Grammar
  19. Hardware
  20. HTML
  21. HTTP
  22. Humour
  23. Idea
  24. Information Architecture
  25. JavaScript
  26. jQuery
  27. Lean
  28. Life
  29. Linux
  30. Literature
  31. Mac OS X
  32. Management
  33. Meme
  34. Microformats
  35. Monday
  36. MySQL
  37. Networking
  38. News
  39. Personal
  40. Photoshop
  41. PHP
  42. Process
  43. Python
  44. Reference
  45. REST
  46. Science
  47. SEO
  48. Server
  49. Site
  50. Sitepimp
  51. Social
  52. Spelling
  53. Syndication
  54. Testing
  55. The Future
  56. Thoughts
  57. Tools
  58. Tutorial
  59. Tutorials
  60. Typography
  61. UI
  62. UNIX
  63. Virtualisation
  64. Web
  65. Web Standards
  66. Widgets
  67. Wii
  68. Writing
  69. Xbox
  70. XHTML