2010-04-19
Why you don't want to host your MTA machine in the cloud
So one recent tidbit of news from Slashdot is that people are shocked, utterly shocked that some bad people are using EC2 to host machines that do bad stuff and that Amazon is surprisingly ineffective about stopping this.
Well, yes. Hello, here is a newsflash: cheap or free hosting (it's free if you use other people's credit card numbers) attracts bad people like flies to honey, and people operating cheap services rarely (by which I mean 'never') staff up their abuse department adequately. Even if they do, the abuse department is all post facto action and generally ineffective; for every bad person they squash, there's three more than show up tomorrow. This is true not just for Amazon's EC2, it is true for any cloud computing system, because they all have the same problem.
(This is happening to EC2 most visibly probably because it is the largest, most popular, best, and easiest to start using. Expect similar stories about everyone else's clouds too.)
Also, much like file sharing services, they cannot magically fix the problem and stay in business. The very things that make them attractive and useful make them abuseable. If you can easily open an account and spin up some instances, so can a spammer or a cracker. If your instance can send out email and make outgoing connections, so can theirs.
Thus, my long term prediction is that you do not want to host an MTA machine in the cloud (any cloud), or at least you want to have a plan for getting a dedicated machine with dedicated (and clean) IP addresses when your cloud-hosted MTA starts getting blocked simply because it has a cloud IP address. Because I really do think that over the long term, much of the cloud vendor IP address space is inevitably going to wind up in blacklists.
(Perhaps cloud vendors will start trying to get around this by offering a separate 'clean' section of IP address space for their proven, long-term customers.)
2010-04-11
The comedy potential inherent in people reusing your address space
For my non-sins, I used to be one of the people who saw email complaints
about UofT-wide spam issues (as opposed to spam issues for the specific
subdomains that I was responsible for). As part of this, every so often
we would get a complaint saying that a UofT IP address (usually but not
always in 128.100.0.*) had spammed people, with Received: headers
included so that we could see this ourselves.
There were two problems with these complaints. First, invariably the
IP address was not in use (and to make it sure the 128.100.0.* subnet
has never been assigned or routed on the campus backbone). Second, the
Received: header with our IP address in it was never the most recent
Received: header; there was always another machine that had touched
the message after it.
(Normally this is the sign of a compromised machine that is forging
Received: headers, although not in these cases.)
Eventually we worked out what was going on. Somewhere (apparently in Europe), sometime, some people writing documentation for a firewall or a 'how to plan your network' or something had decided to use 128.100/16 as the example internal network that they were configuring things for. Naturally, people using the documentation had decided to imitate this example and had set up their 'inside the company' network using 128.100.* addresses, often very low in the address space (hence 128.100.0.* addresses).
Equally naturally, people who do this sort of thing often have
vulnerable mailers, so they got exploited for spam. The spam email went
through their internal machines, picking up their internal 128.100.* IP
addresses in the Received: headers, got relayed through their outbound
gateways, and was delivered to unhappy people. Some of those people
looked at the Received: headers, found our IPs, and sent complaints.
Confusing comedy then ensued.
(Of course we couldn't send grumpy complaints to the companies at fault, since their routing and firewalls didn't permit them to talk to us. In fact this was one of the signs we used to figure out the problem; machines in 128.100.* couldn't talk to their external mail servers, but other on-campus machines in a different subnet could.)