Exim 4.69 denying outbound mail due to syntactically invalid EHLO (bizarre pseudo-MAC FQDN)

Question

Since yesterday (new router, which I suspect is the root cause) a client's been having trouble sending email. Receiving is fine, just the outbound is constantly failing.

Tailing Exim's mainlog, this is the EHLO being presented, and the reason Exim is kicking it back:

2013-03-09 15:07:00 SMTP connection from host109-155-115-197.range109-155.btcentralplus.com (unknown-68:a8:6d:03:cf:6e.home) [109.155.115.197]:52877 

followed by

rejected EHLO from host109-155-115-197.range109-155.btcentralplus.com [109.155.115.197]:52848 I=[213.229.88.78]:587: syntactically invalid argument(s): unknown-68:a8:6d:03:cf:6e.home  

Adding a colon to helo_allowed_chars in exim.conf, the mails flow as expected:

Received: from host109-155-115-197.range109-155.btcentralplus.com ([109.155.115.197]:52913 helo=unknown-68:a8:6d:03:cf:6e.home)

The mail client in question is Mail.app,

Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)

I suppose my question is threefold:

1. Why do BT Home Hubs generate these clearly nonsensical local FQDNs?
2. Why does OSX blindly accept any old weird, noncompliant local hostname?
3. Why does Mail.app blindly accept this weird, noncompliant local hostname when sending outbound email - even though it is clearly illegal and will fail an RFC check?
4. Why don't I see this problem more often? This is the first time I've had someone say their outbound email isn't working, and I've set up email on many Macs using Mail.app, all of which are merrily sending and receiving as I type. (I can see them in Exim's mainlog.)

Looking for other BT Home Hub traffic, I can see an incoming connecting using one whose EHLO looks more standardised:

2013-03-07 20:04:17 H=host81-156-4-96.range81-156.btcentralplus.com (BThomehub.home)

No idea whether that's a Mac or PC generating it though, it's coming from the outside.

I'm in the process of updating this server to latest stable builds, including Exim (it's currently running 4.69). I don't want to leave this RFC hack in place in the Exim conf, there must be a neater way of providing for this problem if a user presents valid credentials.

Is every BT Broadband customer using a Mac actually encountering this same problem with Exim-facilitated emails - and they just don't realise it? I've had to work with Home Hubs before including with Macs in the environment and I've never seen a pseudo-MAC address like unknown-68:a8:6d:03:cf:6e.home assigned to a networked device, I've only usually ever seen hostnames mapped to devices like that in the LAN section of a router where it can't detect the device type or hostname so just shows its MAC address with default gunk prepended and appended.

More pressing is trying to figure out why this data should even be being presented to a mailserver, I don't wish to support this hack for much longer. I can't even guarantee it will work after an Exim update but I've no intention of postponing a server upgrade to support a noncompliant client.

Answer 1

Looks like someone somehow didn't set a computer name for their Mac. Try having the client set a computer name by going to System Preferences then Sharing.

Answer 2

Read message #24 on http://business.forums.bt.com/t5/Email/email-on-Mac-problem-sending/td-p/46630/page/3. Message #26 also has a slightly easier test/fix, where he says:

change the 'Computer Name' to have only letters and numbers - no spaces or punctuation/special characters

e.g. I had "Ian's MacBook Air" and changed to "iansmacbookair"

REBOOT the mac

SMTP will burst into life

Then he says you can change it back to whatever you want because the router only attempts to resolve the hostname once. He did not state whether this survived a router power cycle, but I bet it does not, so you would have to repeat every time the router was power cycled. To me the question #24 is the better, more proper, long term fix.