Re: [tlug] outsourcing email service

["Jonathan Q" <jq@example.com>]

On 9/14/2006, "Micheal E. Cooper" <mcooper@example.com> wrote:


>But I would also like to get experience (even biased), personal input
>from TLUGgers, to make sense of the noise on the net.
>
>What do you think about the wisdom of outsourcing email to an off-site


I work for one of the major providers in that space, so my advice should
not be considered unbiased, although before joining them, I was a
network engineer and mail admin at GOL, so I do now how it is on both
sides of the fence.

I think it's a great idea in many respects, and that's why so many
Fortune 500 companies, among others, augment their internal email
infrastructure by outsourcing to a company that can provide anti-spam,
anti-virus, disaster recovery archiving (for Sarbanes-Oxley compliance,
having good archives in case of lawsuits or SEC investigations, etc.),
policy compliance, disaster recovery, etc.,  so that they have a robust
mail system *beyond* their network edge to take the first brunt of
whatever is bad out there and pass along only what is left.

A typical customer of our service will point their MX record at us and
accept mail only from our datacenter IPs. This makes setup a snap, since
all they have to do is change the MX record and make some firewall
adjustments. This is the same approach used by our two largest
competitors and, I'm sure, by numerous smaller ones.

Besides the advantages listed above, it makes your inbound mail much
harder to DDOS, since a service like ours will have a very large number
of MXes in data centers around the world, and a lot of geographically
distributed name servers as well, with huge pipes to all.  While it is
possible for a large enough company with deep enough pockets to
duplicate that level of mail infrastructure on its own, it doesn't
always make financial sense to do so. Duplicating the level of filtering
and other services an outsourcing company can provide is tougher. Like
our biggest competitors, we've been in this business for years and
didn't develop our technologies and techniques overnight.

Is it worth the price? That depends in a lot of things, including how
much in-house talent you have to run your mail systems and how tolerant
your management is of full or partial interruptions to that service. For
many of our biggest customers, they have large amounts of in-house
talent and could either buy or build filtering systems that ran on their
side of their network edge, however, getting the gain in robustness that
comes with outsourcing would be harder and more expensive to build.

For companies that don't have a lot of in-house talent (maybe they are
small, and one have really great mail admin and they're asking "What
if he gets sloshed at a TLUG nomikai and falls off the train platform
and they clean up what's left with a shop vac?" - which is why I
don't stand near the platform edge after a TLUG nomikai - or pretty
much anytime, really, but especially then), it tends to make a lot of
financial sense to outsource it rather than hire in more talent and then
spend money building out more infrastructure.

Can a skilled mail admin build a filtering system that works about as
well as the services, even if the budget isn't there to build a global
infrastructure? Yes, I think so, especially when you're only dealing
with a single domain, as oposed to the thousands of domains whose
sometimes competing ideas of what is and is not spam that we have to
deal with. There are a lot of open source software tools and free as in
beer RBL services that you can put together into a comprehensive,
multi-layered spam filtering system. There is also some free anti-virus
out there, such as clam-av, but that's an area where you're more
likely to wind up spending some money. Outsourcing companies tyipcally
use an array of AV services to keep all their AV eggs out of one basket.

The above opinions are solely mine, not those of my employer, blah blah
blah, and should not be regarded as unbiased but are my honest opinions
on outsourced mail systems.

HTH,

Jonathan