All the cool kids have web servers, but all the REALLY cool kids have web servers with the ability to send e-mail. In days of yore, when dragons roamed the Internet and a web page with a graphical background was considered a novelty, sending e-mail from your home was as easy as setting up sendmail (or your preferred MTA) and letting ‘er rip. Things are different these days, though, as spammers long ago ruined it for everyone and made doing your own e-mail a lot more difficult.
If you’re doing your web hosting through an actual hosting provider, then chances are you already have some avenue available for your web server or its applications to send e-mail; if you’re hosting out of your basement or closet, though, like I am, it can be a little more complicated. The first obstacle is that most ISPs will block the standard SMTP TCP ports; even if you get past that (by having an unblocked business-class connection, for example), damn near every operating e-mail system in the world blacklists the IP address ranges used by ISPs for customer connections, in order to stop infected home PCs from drowning them with viagra spam.
The solution is mail relaying, where you send e-mail to a trusted e-mail server, which then sends it on to your recipient. Here again spammers have peed in the pool, because no mail server on the Internet is set up to just happily relay messages—in fact, any mail server that is configured as a so-called “open relay” will quickly find itself blacklisted by every other mail server.
But there is an easy way that your web server and its appliations can send e-mail outside of your LAN, and that way is to relay your mail through Google. Specifically, through a Google Apps Standard e-mail address.
This is a tutorial that’s been done elsewhere in lots of different ways—googling around for “postfil gmail relay” or “relay postgix through google apps” will net you scads and scads of results. I’m going to add to the pile by going through the method that I settled on. I was interested in setting up e-mail because I wanted to be notified of changes to the Bigdinosaur.org Minecraft wiki, and DokuWiki has a nice customizable notifiaction system.
You’ll Need an Account
I’m going to assume that if you’re interested in this enough to click through and read up to here, you’ve got Google Apps (standard or pro) set up already, and so you’ll need to create a mailbox for your local Postfix server to authenticate against. I end up sending most of my alerts to that account as well, so that they’re all collected in a single place without cluttering up one of my other mailboxes. So, pop over to your domain’s Google Apps control panel an make an account. Whatever name you create will be displayed in the “From” field in any e-mail relayed through the account, so you’ll want to pick something distinct but not app- or service-specific. I used “postasaurus@bigdinosaur.org,” because it fits with the domain theme and could be used by different applications as a general notification address.
You have the option of using multiple accounts, of course, but I wanted to keep things simple with my configuration, and so I’m using the single address for everything.
You’ll Need an MTA
I elected to use Postfix for my MTA, because it’s become the Internet gold standard for GNU/Linux mailers. As with most things, installing it on Ubuntu is easy:
1 $ sudo aptitude install postfixYes, I’m using aptitude instead of apt-get, and so should you. That’s the subject of another blog post, though.
Postfix installs itself and is immediately ready to begin slinging e-mail, but we need to do some surgery on it first—we have to tell it what it’s allowed to do, where it’s allowed to do it, and for whom. We also need some encrypted credentials for Postfix to use.
Configuring Postfix 1: Credentials
Easy part first: we’re going to add the Google Apps/Gmail server names and the mailbox you created to Postfix’s configuration and get that out of the way. Create a file named passwd
in /etc/postfix/sasl
(and create the directory, too, if it isn’t already there) and make the file’s contents look like this:
Substitute in your information, obviously, using the mailbox address and password you created in the Google Apps control panel. Once the file is saved, we’ll need to transform it into a hashed table, both so that Postfix can properly read it and also so that your mailbox name and password aren’t sitting around in a plaintext file:
1 $ sudo postmap /etc/postfix/sasl/passwdThis will create a file named passwd.db
in the same directory; after that, you can delete the plaintext passwd
file. Alternately, if you’d feel better keeping the file around for whatever reason, you can run chmod 600 passwd
and make it only readable by its owner, which should be root.
Configuring Postfix 2: main.cf
The rest of the changes we need to make are to /etc/postfix/main.cf
. Below is my main.cf
, with hostnames and networks genericized. Modify the default config file to like this one, substituting in your information where required:
The TLS client parameters
section is particularly important. The Google mail servers require you to connect with encryption, and Postfix doesn’t come with any certificate store of its own. Consequently, right out of the box, postfix won’t trust the certificate authority with which Google’s certificates are signed. The way to correct this is to tell Postfix the location of the system’s certifice authority bundle, which on Ubuntu is /etc/ssl/certs/ca-certificate.crt
.
The TLS server parameters
portion may be optional, depending on what you want to do. Postfix prefers encrypted connections from mail clients, and if you’ve got other devices on your LAN which might want to relay e-mail through Postfix and out using the Google Apps mailbox we’ve created—like a printer that wants to e-mail you toner notifications, or a NAS device that wants to e-mail you about failing disks—you’ll need to add SSL/TLS certificate info in here.
There are tutorials out there for generating your own self-signed certs, but in this day and age there’s no excuse for self-signed certs. There are plenty of certificate authorities who will issue you free SSL/TLS certificates that you can use, and which won’t trigger big ugly UNTRUSTED HOST warnings in browsers. I recommend using StartSSL because they’re friendly and respond extremely quickly to support questions (like, usually within minutes). Once you’ve got a certificate and key pair, stash them somewhere appropriately secured on your web server and add them to the main.cf
file above in the correct spots.
And that should do it for the configuration! Restart Postfix:
1 $ sudo /etc/init.d/postfix restartDepending on how Postfix was installed, you might get an error here that looks like this:
1 2 3 4 5 6 * Stopping Postfix Mail Transport Agent postfix postmulti: fatal: /etc/mailname: cannot open file: No such file or directory ...done. * Starting Postfix Mail Transport Agent postfix postmulti: fatal: /etc/mailname: cannot open file: No such file or directory ...done.If so, simply create a text file called mailname
under /etc/
and put in it your server’s FQDN:
Then restart Postfix again.
Checking to See if it All Works
To verify that Postfix can correctly send e-mail, first start watching the Postfix log, like this:
1 $ tail -f /var/log/mail.logThis will open up the Postfix log file and as new entries at added to it, it will automatically update itself in your terminal window. Open up a new window, log into the server you’ve been working on (if necessary), and try to send an e-mail with the sendmail
command:
Use your personal e-mail address with the sendmail command, since that’s where you’ll be sending the e-mail. You’ll have to type the next five lines manually. Enter the correct To:
and From:
addresses (and remember that the From
address is going to be the mailbox you created back at the beginning), give the e-mail a Subject:
and then write a brief message. End the message with a single period on a new line. Once that’s done, Postfix will attempt to deliver it, and you’ll see a bunch of activity in the log window:
If you’ve gotten everything set right, you’ll first see a notice from the Postfix pickup process, then a cleanup notice assigning it a message ID, then a note from the queue manager saying that the message has been queued for sending, then a note from the smtp process saying that it was successfully relayed through smtp.gmail.com (look for status=sent
, along with the 250 2.0.0 OK
part), and then finally a note from the queue manager saying that the e-mail has been removed from the mail queue.
Of course, the real confirmation will be when your e-mail shows up in your inbox!
Postfix is now set to relay e-mails through your Google Apps account, and if you have any applications on your web server that need an e-mail server address so that they can send e-mail, you can now simply give those apps the address of your web server running Postfix. Same thing for printers or other devices on your LAN—if they can send e-mail alerts, you can give them the server’s address and they’ll relay through it, and your alerts will reach you.
Obviously, this post hasn’t covered anything about receiving e-mail with Postfix. I use my Google Apps domain accounts for receiving e-mail, so I have no need for Postfix to be able to fetch any mail for me, but there are tons of other tutorials out on the Internet if you need Postfix to receive mail.
Discussion topic for the original blog entry at: http://blog.bigdinosaur.org//postfix-gmail-and-you