In the end, it is often easiest if you create an email "gateway" that leverages the likelihood of just about everything on your campus being able to throw SMTP at port 25 (even though that's deprecated for mail submission), alongside GSuite for Education's SMTP email relay functionality.
This is particularly important once you start getting serious about email security, and that email from your domain MUST flow through particular email servers (because of SPF, DKIM & DMARC).
Read on for more!
I'm going to assume you're reasonably familiar with Ubuntu - Google any steps that seem confusing, as the Ubuntu community is large, vocal and well supported - your issue will have been seen before and fixed somewhere!
- Install Ubuntu
- Grab your preferred version of Ubuntu Server; an LTS release is a good bet for a long-running service. Install it on a physical or virtual host.
- In the installer, run through the scripted install. For the most part, accept defaults. When it asks what to install, only select OpenSSH server - everything else, you'll add later.
- The server will grab an IP from DHCP - make sure that IP is allowed out through your firewall so it can successfully grab any updates/packages, etc (you can change to a static IP later if you want to). It's typically a good idea to make a reservation for the IP you intend to have that machine run on (but getting the MAC address of the server's NIC before it boots can be a challenge; a LiveCD can help bridge that gap).
- Configure Ubuntu
- Once install is finished, log into the machine with the credentials you created during install.
- Change any network settings you want to in /etc/network/interfaces - many people like to configure a static IP. Your other option is to get the MAC address of that machine (ifconfig eth0 HWaddr - unless of course eth0 has gone away) and put it into DHCP to hand out the "correct" IP every time. In a highly virtualised environment, most things should be configured by DHCP (other than some core routers, and possibly your DHCP servers).
- Configure the most local mirror(s) you know about in /etc/apt/sources.list ; this list is not necessarily comprehensive. (Google if you're not sure how)
- I long ago picked up the habit of using Shorewall firewall instead of the built in one. Install shoreline (apt-get install shorewall).
- Configure shorewall as you want it (remember to make it secure! There are plenty of good examples online, but firewalls are something you need to carefully consider for yourself rather than blindly accepting someone's suggestions).
- Install telnet (useful for testing smtp)
- You probably don't need it, but if you find CLI-only server intimidating, webmin is a wonderful front-end to most things in Ubuntu.
- Configure Postfix
- Execute sudo apt-get install postfix (and any dependencies that crop up).
- In /etc/postfix/main.cf, you'll probably want to have the following, replacing the bits <in angle brackets> with your settings:
- smtpd_use_tls=yes
- smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
- myorigin = <domain.tld>
- mydestination = <FQDN of HOST>, $myhostname, mail, localhost.localdomain, localhost
- relayhost = [smtp-relay.gmail.com]:587
- mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 <space delimited list of any IPs that can send Mail through it, in CIDR format - recommend internal IPs ONLY unless you set up a much more complex configuration with user authentication - which defeats the point. NB this is how you prevent randoms spamming through your system - be restrictive!>
- mynetworks_style = subnet
- smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces
- myhostname = <FQDN of host>
- ...alongside any defaults; save.
- Restart postfix service.
- Configure GSuite for Education
- Make sure you understand any limitations and how they may apply to your site. If you're sending enough email that you're going to hit the limits, you're probably going to need to call in a 3rd party to help you manage your "spam operation" (MailChimp is nice!). Alternatively, set up some other MX records on another (sub)domain for your massive email requirements, and email outside of GSuite!
- Log into your GSuite admin control panel.
- Navigate to the mail setup section. Apps>G Suite>Gmail>Advanced Settings Scroll down to "SMTP relay service"
- Set up your mail relay host details, making sure you configure the correct public IP address there for your mail relay server. If you're not sure what your public IP address is, install lynx on your server, and google "what is my IP", which will return your public IP address.
- Typically, you're really going to be wanting to do this from a static IP address, so if you have to do this, consider that your mail gateway might well break next time you reboot your router, or your ISP changes your DHCP leased IP address for any other reason.
- Make sure this IP is ONLY used by your email gateway server - it should be dedicated to this purpose, and not used to NAT other traffic out of, etc.
- If you need help choosing the right settings for your site, see Google's help page.
- Save.
- Configure your firewall, if necessary
- Configure your firewall (on the host and on your edge) to allow outgoing email from that machine. We've set it up to use encryption through TLS, so if you block outgoing port 25, that should not be a problem - so long as you allow 587 out from the server (or the subnet it lives in) to Google.
- You should block outgoing tcp/25 from your LAN to the Internet, particularly for client and guest traffic. (See e.g. this for some background).
- You may also need to set up src-NAT to appear from a specific IP (or range); I highly recommend you reserve and use a public IP ONLY for your mail server and NOTHING ELSE. Obviously, it should be the IP specified in the mail relay setup in GSuite, above.
- N.B. if you are trying to set up email on a dynamic public IP address (like on a home ADSL connection) you are going to struggle. Pay for a static IP or a small block of them from your ISP. Ideally, ask them to have the PTR resolve the same FQDN as you would put in for an A record for that IP if it is publicly accessible - and certainly do this if you're not relaying through Google (i.e. you run some direct emails - outside the scope of this post).
- Test
- Test that it works. Test from the Ubuntu CLI; test from another machine on your network. Interactive telnet sessions to port 25 work quite well; you can also of course set up an email client program to test; mailx will work for basic CLI email sending.
- Put into production
- Put the host into your monitoring system, with appropriate checks and reporting.
- Point anything that doesn't support modern email standards at your shiny new mail gateway!
- Consider restricting hosts that can use it in either (or both) the firewall or Postfix configurations.
- Make absolutely sure random hosts outside of your network can't use it as an open relay; NAT and RFC1918 addresses are a helpful safeguard, but intentional firewalling (network edge/borders and host) and restrictions in postfix config (allow things through mynetworks - a /32 CIDR netmask is useful to whitelist a single host) are better.
- Remember to regularly check that your server is patched and up to date.
- Make sure if devices or services change IP that you update the firewall and/or postfix configs to match - particularly do so for things you remove where there is a risk some random host will end up getting that permitted IP down the line.
- Another reason you WANT to limit this is that anyone with access to this can "pretend" to be any valid user by "spoofing" the From: field - this is by design, so lock down anything that is allowed to use this facility to prevent embarrassment or more serious repercussions.
- Internet Standards
- You should probably read some applicable RFCs to better understand the complexities of email on the "modern" internet. In particular, https://tools.ietf.org/html/rfc5068, and note that, to some extent, a "mail gateway" of this sort is against this "best practice" - what ultimately it is, of course, is a dirty hack to make things that are NOT modern Email RFC compliant get mail off your campus and into your email system - and then in line/compliant with other best practices like SPF, DKIM and DMARC.
Of course, it should be obvious to the reader that slight tweaks to theses settings will allow you to use Postfix to interface obsolete/buggy gear with just about any service that supports similar mail submission processes.
Links for further reading:
Links for further reading:
No comments:
Post a Comment