Apr 30 2008
Vodafone illegally intercepting 3G-users’ email?
Some of the guys at work have been reporting for several days that they haven’t been able to send email when working off-site and connecting to the internet by their Vodafone 3G dongles.
Specifically, Thunderbird was saying that it received an invalid server response of “421 too many connections”.
I’d never managed to reproduce this from work or home, the mailserver showed no signs of being overloaded, there weren’t masses of TIME_WAIT connections and the high-watermark of file descriptors was fine.
Today I was able to see this in action: our SMTP server apparently returned the 421 error. Our spam-filtering service’s primary SMTP server apparently returned an identical 421, yet the secondary responded correctly.
From several sources, it appears that Vodafone are intercepting all 3G traffic on port 25 and trying to force it through their own servers. How this works when the client then requests a TLS encrypted session is anyone’s guess – but it’s clear that the server(s) that Vodafone is redirecting to are collapsing under the strain.
This seems to be a clear case of (illegally?) intercepting traffic – and the threads linked to above suggest that Vodafone’s support droids are utterly clueless about the situation.
We took the only only sensible route around this problem – open up port 465 (secure SMTP) on the mailserver and allow incoming SSL connections, in addition to the previous solution of relying on the client to issue a STARTTLS command over the standard port 25.
It’s a sad state of affairs when a carrier who you’re paying a significant sum to for data transfer breaks business-critical functionality – namely, the ability to send email – without any notification, and shows every sign of intentionally intercepting potentially sensitive data. Even if this is an honest mistake or misconfiguration, Vodafone mustn’t be allowed to get away with it without admitting what they know and what they’re attempting to do.
Encrypt everything people… and stay safe out there.
1st July 2009 @ 12:22 pm
oh don’t even trust encryption, but also know you can use alternative smtp ports if you’re smtp server uses that function as ours does…
You don’t even need to do ssl, if your e-mail server uses an addiotional alternative smtp port like ours does on port 366 then just do the following:
server for outgoing mail: smtp.provider.com:366
works like a charm, if you then also use an alternative ssl smtp port then you’re pretty well protected.
2nd July 2009 @ 8:06 am
So you’re advocating security through obscurity – and still transmitting messages in the clear – rather than using industry-standard and proven encryption technology to ensure that you’re talking to the server you think you’re talking to?
Whilst using an alternative port should work for now, if you’re not confirming the server’s identity then communications could still be intercepted at any point, and using alternative ports does require additional client configuration.
The only downside of enabling SSL is that establishing a connection is more computationally expensive, leading to higher load on the mail server.