Invariant Properties

  • rss
  • Home

Configuring Ubuntu 11.04 To Send Mail via Google Apps

Bear Giles | May 10, 2011

Like many people I’ve abandoned running my own mail servers due to the sheer volume of spam and malware.  Google Apps provides a nice solution – to the rest of the world I’m still running my own servers but Google deals with the spam, the sender authentication records, etc.

Aside: I can’t say too many good things about Google Apps. It is free for less than 10 users (according to recent email) and educational facilities and only $50/user/year for the business version. You aren’t even forced to use the webmail interface – it supports both IMAP and POP so you can use a traditional standalone mail application like thunderbird or evolution.

One big downside is that locally generated mail tended to get lost. I think of it as jurisdictional issues – my mail server knows my domain and doesn’t think it needs to send the mail to another system. It handles my domain! There’s probably a simple solution to this but I’ve never taken the time to search for it.

Fortunately it’s easy with Ubuntu 11.04.

  1. Install postfix if it isn’t installed. In this case specify a satellite site configuration.
  2. Edit /etc/postfix/main.cf and add the following lines:
    1. # comment out the following line - we want all mail to be forwarded
    2. #mydestination = domain, hostname, localhost.localdomain, etc.
    3. relayhost = [smtp.gmail.com]:587
    4. smtp_sasl_auth_enable = yes
    5. smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    6. smtp_sasl_mechanism_filter = login
    7. smtp_sasl_security_options = noanonyous
    8. smtp_sasl_tls_security_options = noanonymous
    9. smtp_use_tls = yes
    10. # the next few items force the use of TLS encryption on outbound email
    11. smtp_tls_per_site = hash:/etc/postfix/tls_per_site
    12. # this will allow postfix to talk to any site Firefox recognizes
    13. #smtp_tls_CApath = /usr/share/ca-certificates/mozilla
    14. # this is much more restrictive - it will recognize GA/gmail.
    15. smtp_tls_CAfile = /usr/share/ca-certificates/mozilla/Equifax
    # comment out the following line - we want all mail to be forwarded
    #mydestination = domain, hostname, localhost.localdomain, etc.
    relayhost = [smtp.gmail.com]:587
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_mechanism_filter = login
    smtp_sasl_security_options = noanonyous
    smtp_sasl_tls_security_options = noanonymous
    smtp_use_tls = yes
    # the next few items force the use of TLS encryption on outbound email
    smtp_tls_per_site = hash:/etc/postfix/tls_per_site
    # this will allow postfix to talk to any site Firefox recognizes
    #smtp_tls_CApath = /usr/share/ca-certificates/mozilla
    # this is much more restrictive - it will recognize GA/gmail.
    smtp_tls_CAfile = /usr/share/ca-certificates/mozilla/Equifax
  3. Create the /etc/password/sasl_passwd file and add your GA (or gmail) credentials. IMPORTANT: as far as GA (or gmail) is concerned all of the mail sent from this system comes from you so you will want to take a different approach if multiple people use this system! Specifically you’ll want to look at setting up an ‘outbound gateway’ via Google Apps for Business or Education.
    1. [smtp.gmail.com]:587 user@mydomain.com:password
    [smtp.gmail.com]:587 user@mydomain.com:password
  4. Create the /etc/postfix/tls_per_site file and specify that mail sent to GA (or gmail) MUST be encrypted. This map allows us to use different policies if we have explicit ‘transport’ entries for other destinations.
    1. [smtp.gmail.com]:587 MUST
    [smtp.gmail.com]:587 MUST
  5. Create the hash files and change the permissions on the password files.
    1. $ postmap /etc/postfix/sasl_passwd
    2. $ chmod 0640 /etc/postfix/sasl_passwd*
    3. $ postmap /etc/postfix/tls_per_site
    $ postmap /etc/postfix/sasl_passwd
    $ chmod 0640 /etc/postfix/sasl_passwd*
    $ postmap /etc/postfix/tls_per_site
  6. Make a small change in /etc/postfix/master.cf around line 36.
    1. smtp      unix  -       -       <strong>n</strong> -       -       smtp# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
    2. relay     unix  -       -       <strong>n</strong> -       -       smtp        -o smtp_fallback_relay=
    smtp      unix  -       -       <strong>n</strong> -       -       smtp# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
    relay     unix  -       -       <strong>n</strong> -       -       smtp        -o smtp_fallback_relay=
  7. Add yourself to /etc/aliases.
    1. # See man 5 aliases for format
    2. postmaster:    root
    3. root: user@mydomain.com
    # See man 5 aliases for format
    postmaster:    root
    root: user@mydomain.com
  8. Verify that everything is okay, rebuild the alias file and restart the server.
    1. $ sudo postfix check
    2. $ sudo newaliases
    3. $ sudo service postfix restart
    $ sudo postfix check
    $ sudo newaliases
    $ sudo service postfix restart

Improving Security: Restricting Certificate Authorities

Adding TLS encryption is only half of the problem. We need to make sure that we’re actually talking to GA/gmail. For that we need to verify the GA/gmail certificate – in fact postfix will refuse to deliver the mail if it can’t verify the certificate of the remote system.

This is simple in concept but it requires us to trust the certificate authorities that sign these certificates. Firefox (and Debian/Ubuntu) vet them but the nature of the current certificate authority architecture means that ANY CA can sign a certificate for ANY server. This means that some obscure CA in Unfreedonia under government pressure can sign a certificate for ‘smtp.gmail.com’ and it will be accepted by postfix as long as that certificate is in the CApath.

We can improve the situation by specifying only the file used by GA/gmail’s certificate. We can get that this by looking at the postfix logs and a bit of experimentation. I gave the appropriate CAfile above.

As an aside: we can’t delete the standard CAs in either firefox or chrome but we can remove permissions so we can greatly reduce the number of CAs we trust. I blogged about this a few months ago.

Categories
linux
Comments rss
Comments rss
Trackback
Trackback

« Obvious-in-Hindsight Linux Recovery Preparation Rethinking ‘dump’ »

Leave a Reply

Click here to cancel reply.

You must be logged in to post a comment.

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,793 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox