Mostly about my amusement

Tag: Postfix (page 1 of 1)

Moving some users to Google Apps for mail

I host the domain and also handle the mail delivery.  The mail ultimately ends up in Stefan’s house via his DSL line.

That DSL line has been prone to problems so I played with the idea of moving the mail to another server or VPS. But handling spam and keeping my web mail software up to date is a pain. So I wanted to move my whole domain to Google Apps for mail handling. Google is much better at distributed web mail systems and spam fighting than I am.

This was not universally accepted by all of my users. So I found a way to selectively send mail to Google Apps on a per user basis.

1. Sign up your domain for Google Apps

Okay, that one is a no brainer.  I authenticated my domain by inserting a Google supplied CNAME record into my zone file.  That established that I was the one in charge of my domain. Google lets you use it at no charge for up to 50 users.

In Google Apps I added another domain to my profile called  This way mail from Google gets delivered as and Google will also receive mail for

2. DNS changes

I set up a sub-domain called  The DNS records for this domain are pretty sparse and only contain MX records that Google provides for users to point their domain to.  These came straight out of Google’s instructions. In my zone file I bumped the serial number and added these lines:      MX 10      MX 20      MX 20      MX 30      MX 30      MX 30      MX 30

Then I created a couple of  A records for pointing to two servers I run Apache2 on. More on this later.

3. Postfix recipient rewriting

The magic happens on my two Postfix MTAs. When the primary mail server goes down, mail queues up on my secondary mail server.  It will stay there until the primary comes back. That sucks; last time we had an outage, the mail server was down for almost 24 hours.

The solution is to have Postfix receive the mail, rewrite the address to the sub-domain, and send it along for delivery.

In my /etc/postfix/ file I added this line

recipient_canonical_maps = hash:/etc/postfix/recipient_canonical_maps</pre>
In the file /etc/postfix/recipient_canonical_maps I had something like this:
<pre lang="text">

This let me turn on Google mail handling on a per user basis. I ran postmap hash:/etc/postfix/recipient_canonical_maps and restarted postfix on my servers.

Now if my mail server tanks again, as long as the secondary is up, I still get my mail via Google Apps.

4. Lazy web mail URL

The two servers that are being pointed to as I created an Apache2 vhost on each one for that server name. In the root directory for the new vhost I created a small index.php with the following content:

header("HTTP/1.1 301 Moved Permanently");

I’m lazy. I can remember easier than

Update: Or I could follow the directions and in my Google Apps dashboard just set a customized URL for mail.

After setting that up in my dashboard, I updated the DNS record to be a CNAME pointing to

5. Test everything

Using an IMAP client (after I turned IMAP on in my Google Apps mail) I sent and received mail with my primary server’s postfix shutdown. That worked perfectly.

I also had other people in my domain send and receive mail just to make sure I did not bork that up too. All was good and we were all able to send and receive mail.

That’s it. As long as I create accounts in Google Apps and maintain the recipient_canonical_maps file, I’ve got a good solution for fighting spam with a good web mail client without impacting my other users.

Bad mail queuing in Postfix

Yesterday around 12:36 AM my main server mowgli went into a temporay coma (a disk volume fell down and did not get back up) and was not receiving mail.

No problem, thanks to the magic of DNS MX records, mail goes to my backup server dixie. Good thing I was clever and had dixie forward all mail to Optimum Online’s mail relay… when the mail relay got the mail it tried to deliver it to mowgli (who was down) and then back to dixie. The mail dixie got was sent into a loop with my ISP’s mail relay.

Each hop is added to the messages SMTP header and when an MTA sees that it is looping with itself then it typically sends the sender a non-delivery message and discards the original mail.

I lost about 20 hours of mail messages for my domain. Once mowgli was fixed I made a change to mowgli’s Postfix configuration. In the file I changed this line from

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_rbl_client

to now include a whitelist

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_client_access hash:/etc/postfix/whitelist, reject_rbl_client

The /etc/postfix/whitelist file just contains one line for dixie’s IP address OK

I ran postmap hash:/etc/postfix/whitelist and tested. From dixie I was able to telnet to mowgli on TCP port 25 and send mail by typing in the SMTP commands directly. Before this I would get an error message like

554 Service unavailable; Client host [] blocked using;

Now my main server accepts mail just from that IP address on the whitelist before the Spamhaus check occurs. The reject_rbl_client check is still working (open mail relays are BAD) it’s just my one IP address that gets a pass.

The configuration on my backup server dixie was simple. I added to one line

transport_maps = hash:/etc/postfix/transport

The file /etc/postfix/transport contained smtp:[]

I ran postmap hash:/etc/postfix/transport and restarted postfix. Now when dixie needs to deliver mail to it sends it directly to mowgli. If mowgli is unreachable it will just queue up the mail until mowgli becomes available. Every other domain gets forwarded to my ISP’s mail relay and all is good.