I often work with smaller organisations make their IT run smarter and better and allow them to save money. An on running theme I’ve come across for the last couple of years is internet speeds.
For instance one company I’ve worked with is the parent company for 4 other organisation, they run some centralised services from their head office location which all the other companies connect to over a business DSL service with a VPN ontop. Each company also runs it’s own mail server on their own network.
A theme I discovered was that of the availability of these services being ran. Server was fine, no bottle necks there, but looking at the DSL utilisation it was near enough at full capacity 24 hours a day. Now over here in the UK synchronous connectivity is very expensive for SMEs so we had to look at something else rather than throwing more bandwidth at it.
So I decided to investigate what was going on over this connection. I shouldn’t have been shocked when I discovered that with each network hosting it’s own email server that spam was causing these connections to virtually come to a standstill. It wasn’t necessarily spam getting through was the problem (which is wasn’t), it was spam being sent down a small pipe and the implications of rejecting it over the same pipe. Spam wastes precious bandwidth.
Now being looking at this in perspective each company was using it’s DSL as it’s SMTP pipe and MX record with filtering done once it had been fed down this finite conection. In the end we hit on an easy solution; do the spam filtering before it hits the DSL connection, it sounded that simple it may just work…
We looked at third part email security providers, but for the budget we couldn’t justify spending that amount of money. So we thought we’d do it ourself.
Having used Postfix for a number of years I know of the flexibility and security it offered and it seemed to be a perfect solution to this problem. So with our limited budget we went and purchased a Linux VPS, complete with Debian, installed Postfix, configured it with spam and virus filtering, then changed the companies MX records accordingly (after changing some local firewall settings I may add).
We set up the Postfix configuration to look like this:
main.cf
relay_domains = hash:/etc/postfix/relay_domains
mynetworks = hash:/etc/postfix/mynetworks
transport_maps = hash:/etc/postfix/transport
smtpd_client_restrictions = permit_tls_all_clientcerts
reject_rbl_client b.barracudacentral.org
reject_unauth_pipelining
check_client_access hash:/etc/postfix/rbl_override
reject_rbl_client bl.spamcop.net
reject_rbl_client cbl.abuseat.org
reject_rbl_client zen.spamhaus.org
check_client_access hash:/etc/postfix/dspam_filter_access
relay_domains
companya.com
companyb.com
companyc.com
companyd.com
mynetworks
127.0.0.1
111.111.111.111
111.111.112.112
111.111.113.113
111.111.114.114
transport
companya.com smtp:[111.111.111.111]
companyb.com smtp:[111.111.112.112]
companyc.com smtp:[111.111.113.113]
companyd.com smtp:[111.111.114.114]
We set up the local SMTP servers to relay through the VPS which was being used as an MTA Smarthost, then we configured the firewalls to only allow access via port 25 from the IP of the VPS.
Now all the companies benefit from being able to use their DSL connections for what they want as opposed to filtering for junk email. Other benefits we quickly discovered was that intra-company emails were being delivered near enough instantly and the services being ran between the group also benefited from the planned massive speed bump. Another advantage we got was that is the DSL connections went down for a reason (ie maintenance), the VPS would sit online holding the mail until the DSL came back online again.
A good job: done right, very cost effectively and done quickly.
No Comment