Log in

No account? Create an account


Can't send mail from an Apple Mac via a BT Internet connection.

« previous entry | next entry »
30th Nov 2012 | 17:45

This morning we got a problem report from a user who couldn't send mail, because our message submission servers were rejecting their MUA's EHLO command because the host name was syntactically invalid. The symptoms were a lot like this complaint on the BT forums except our user was using Thunderbird. In particular the hostname had the same form, unknown-11:22:33:44:55:66.home, where the part in the middle looked like an embedded ethernet address including the colons that triggered the syntax error.

I wondered where this bogus hostname was coming from so I asked the user to look at their Mac's various hostname settings. I had a look in our logs to see if other people were having the same problem. Yes, a dozen or two, and all of them were using BT Internet, and all of the ethernet addresses in their hostnames were allocated to Apple.

A lot of our BT users have hostnames like unknown-11-22-33-44-55-66.home where the colons in the ethernet address have been replaced by hyphens. But it seems that some versions of the BT hub have broken hostname allocation that fails to use the correct syntax. You can change the settings on the hub to allocate a hostname with valid syntax but you have to do this separately for each computer that connects to your LAN. I believe (but I haven't checked) that the hub implements a fake .home TLD so that DNS "works" for computers on the LAN.

When a Mac OS computer connects to a network it likes to automatically adjust its hostname to match the network's idea of its name, so on a LAN managed by a broken BT hub it ends up with a bogus hostname containing colons. You can force the Mac to use a sensible hostname either globally or (as in those instructions) just in a particular location.

Most MUAs construct their EHLO commands using the computer's hostname. Most mail servers reject EHLO commands with invalid syntax (though underscores are often given a pass). So, if you try to send mail from a Mac on a BT connection then it is likely to fail in this way.

This is a stupid and depressing bug, and the workarounds available to the user are all rather horrible. It would be a waste of time to ask the affected users to do their own workarounds and complaints to BT - and it seems most of them are oblivious to the failure.

So I decided to tweak the configuration on our message submission servers to ignore the syntax of the client hostname. In Exim you can do this using helo_accept_junk_hosts = * preceded by a comment explaining why BT Hubs suck.

| Leave a comment |

Comments {6}

from: pir
date: 30th Nov 2012 20:08 (UTC)

I tweaked my personal exim config to ignore those syntax errors if someone used a high port (like the submission port) after failing to connect to my own mail server from an Android device with K-9. I think the bug got fixed but it's still, alas, useful. I don't turn it off globally since it appears to stop as lot of spam and I don't have many users to worry about :)

Reply | Thread

Tony Finch

from: fanf
date: 1st Dec 2012 11:59 (UTC)

I think the option exists for just this kind of reason, but this is the first time I have had any evidence of widespread stupid software. I am also keeping the syntax checks for other contexts - our MX and smart host services. As you say, HELO domains are really effective inputs for bot detectors.

Our actual configuration is a bit more complicated: there is a string expansion that expands to * if the server IP address is a message submission service address, and : for other server addresses. We use IP addresses rather than just ports because it allows better behavioural isolation, for instance a compromised host on our network can't use its domain's MX record to locate an outgoing mail relay.

Reply | Parent | Thread

from: syscomet
date: 28th Mar 2013 02:41 (UTC)

Is it that much harder for the bot to do an SRV lookup for the _submission._tcp record for the local domain? Or do you not support that client autoconfiguration?

Reply | Parent | Thread

Tony Finch

from: fanf
date: 28th Mar 2013 09:56 (UTC)

We don't support it at the moment, mainly because the email address most people use is @cam.ac.uk and this is a virtual domain backed by several separate real domains, more than just hermes.cam.ac.uk. So SRV records on cam.ac.uk would often be wrong, and SRV records on the servers' native domains would not help very much. Most department/college subdomains are virtual domains also, where it would not make sense to have SRV records.

Our submission servers require TLS and AUTH so if a spammer has the necessary credentials they almost certainly have the hostname too.

In the instance I was thinking of (many years ago), a spammer used an open proxy to send out via our mail relay. Our relay does not have an easily guessable name, so they would have either had to do an MX lookup or read our documentation to discover it...

Reply | Parent | Thread

Gerald the cuddly duck

from: gerald_duck
date: 1st Dec 2012 18:30 (UTC)

But what does it then do with the bogus hostname if it accepts it? Sanitise it?

I thought the EHLO hostname tended to end up in Received: headers, so doesn't letting through a bogus one verbatim in turn mean non-conforming e-mails?

Reply | Thread

Tony Finch

from: fanf
date: 5th Dec 2012 10:17 (UTC)

Yes I just dump the garbage in the Received: header. Exim's Received: headers don't follow the standard properly anyway.

Reply | Parent | Thread