Virtual mail hosts: 255 character limit on SPF records

Question

This one was a surprise to me, and caused a lot of headache, so I thought I'd pass it along.
I'm running multiple virtual mail hosts off of my doughty PowerMac single G5 1.8GHz running OS X Server 10.4.11. Some of the outgoing mail was being bounced as spam because a) there wasn't an SPF record on any of the domains and b) the domain of the mailserver didn't always match the domain of the sender. (Most often, it went out under the hostname of the server, cerberus.limbo.jcf.org—which is useless, since that's a LAN address.)
Trying to be a good citizen (and make sure that all of everyone's mail got through), I added SPF records that explicitly named each and every mailserver on the machine, just so that everything was clear and aboveboard—but they ended up being about 500 characters long.
Fastforward a week or two... and I was having problems with my DNS zones loading—I'd get errors that they'd timed out. After pulling my hair out for a while, I discovered that TXT records have a limit of 255 characters (including spaces, etc.) Some folks running servers on non-OS X Server machines have split the records over multiple TXT records (does that even work?), but you get exactly one TXT record per OS X Server machine: the Comment box.
I've now simplified the SPF records so that they read something like this:
+v=spf1 a mx mx:cerberus.limbo.jcf.org mx:cerberus.jcf.org mx:jcf.org ip:173.164.140.96/30 ip:207.58.140.213/30 include:comcast.businessclass.net include:comcast.com -all+
To translate:
• +v=spf1 a mx+ It authorizes deliveries from any IP listed in the DNS zone, and from any mailserver defined in the zone
• +mx:cerberus.limbo.jcf.org mx:cerberus.jcf.org mx:jcf.org+ It also explicitly authorizes deliveries from the server's main LAN and internet DNS names as well as the domain of the foundation for which I work (and through which emails are occasionally relayed)
• +ip:173.164.140.96/30 ip:207.58.140.213/30+ Next it authorizes the public static IP blocks for the server and the foundation's remote server
• +include:comcast.businessclass.net include:comcast.com+ Finally it includes the domain names of the ISP through which most of the mail are relayed
• -all The last item says that if the mail didn't originate from one of those addresses, it isn't ours.
(I think that I've got that right. If I've botched it anywhere, let me know, okay?)
That's 169 characters. The DNS zones loaded happily, and the mail seems to be going out without getting bounced. So far so good!
(There's probably a way to get the hostname on each email to match the domain from which it is being addressed, but I haven't gotten there yet.)
Message was edited by: David Kudler

Answer 1

Most often, it went out under the hostname of the server, cerberus.limbo.jcf.org—which is useless, since that's a LAN address.
You can control this via the myhostname setting in Postfix. This defines the name it uses to identify itself to remote mail servers, which sounds like it'll address a lot of your issues.
I added SPF records that explicitly named each and every mailserver on the machine, just so that everything was clear and aboveboard—but they ended up being about 500 characters long.
OK, this doesn't make sense. You don't need to list every virtual hostname for every domain.
All you need to do is add this specific mail server's address in each domain.
There's no requirement that the hostname of the mail server matches the domain name, so it's entirely valid to create an SPF record in domain1.com that lists mailserver.someotherdomain.com as authoritative. Then, as long as postfix's myhostname says it's mailserver.someotherdomain.com and your reverse DNS resolves to that address your problem is solved.
...but you get exactly one TXT record per OS X Server machine: the Comment box.
Unless you edit your zone file directly and add whatever other records you like. However, given the above, I don't think the 255-character limit should be an issue.
Even if you didn't want to mess with your zone files directly there's still a way around that - SPF allows for an 'include' record which basically tells remote servers to include the record from some other domain, so for each domain you could just tell it to include some other domain's record (which, in turn, could include another domain) allowing virtually unlimited record length (or, at least, 255 characters per domain you manage).
SPF Includes are covered here.
• include:comcast.businessclass.net include:comcast.com Finally it includes the domain names of the ISP through which most of the mail are relayed
Bzzzz. You've now allowed any other customer of comcastbusiness.net and comcast.com to send mail on your behalf. You probably don't want to do that. When you consider that 'comcast.com' includes every one of their residential customers you can see that you really don't want to do that.