Ever heard of publicaster.com? Yeah, me neither. Apparently one of our customers has as he attempted to send an email to them last week. Unfortunately, it got stuck in the queue because of a combination between a weird configuration in publicaster.com's DNS and Exim 3.

For some reason known only to a small-minded DNS admin, publicaster.com decided to list 235 hosts as their MX. Here's a snippet:

publicaster.com mail is handled by 229 mail219.publicaster.com.
publicaster.com mail is handled by 230 mail220.publicaster.com.
publicaster.com mail is handled by 231 mail221.publicaster.com.
publicaster.com mail is handled by 232 mail222.publicaster.com.
publicaster.com mail is handled by 233 mail223.publicaster.com.
publicaster.com mail is handled by 234 mail224.publicaster.com.
publicaster.com mail is handled by 235 mail225.publicaster.com.

It makes no sense to me why they would waste nearly an entire /24 for such a thing. The DNS response is so big it had to fall back to TCP. There's another waste of bandwidth.

OK, so why is this a problem? Apparently it causes a crash in Exim 3.35 which we're still running. Yeah, I know. 4.50 is out. Tough beans. This is what I've got to work with. So I came up with a workaround in my exim.conf to get mail delivered to them despite their best efforts.

manual_override:
   driver = domainlist
   domains = /etc/exim/manual-override.domains
   search_type = lsearch
   route_file = /etc/exim/manual-override.routes

Take that!