I wrote:
Second, you don't need friggin' multiple records. Just the one.
tl;dr: Wrong. _My_ domain does fine with a single record, but BALUG's case differs.
I had a nagging bad feeling about the above, so (because I'm still suffering a bit of insomnia on account of jetlag, and lying in bed awake), I did some double-checking, and in all good conscience must report that the above is in error.
First, my (not good enough) excuse: In my own use-case, for domain linuxmafia.com, _all_ outbound mail originates from FQDN linuxmafia.com without a qualifier, e.g., there is no 'lists.linuxmafia.com' that sends out mail -- unlike the case with, say, BALUG. Consequently, my having a SPF RR for _only_ FQDN 'linuxmafia.com' solves my domain's needs -- but only because mine is a limiting case that doesn't generalise.
Or to put it another way, my linuxmafia.com SPF RR is correct for my domain solely because of the very simple way outbound mail is handled, but I erred in guessing how it would have applied to a more complex setup.
I discovered my error while reading about how SPF records apply to subdomains -- and, the more I read, the more I started to realise that my assumption that a single SPF TXT record referencing the unqualified domain (as mine does) automatically covers arbitrary hosts/subdomains of that domain is totally wrong. It doesn't. Here's an extremely useful page: http://www.openspf.org/FAQ/Common_mistakes
I knew for certain that I'd overgeneralised what my single SPF RR would cover when I read this tip:
Publish null SPF records for your domains that don't send mail Once you've protected your mail sending domains with SPF, if someone is trying to spoof you, then first thing they will try is to spoof your non-mail sending domains. Publishing "v=spf1 -all" says that a domain sends no mail. As an example, you might publish:
example.com. IN TXT "v=spf1 a:mail.example.com -all" mail.example.com. IN TXT "v=spf1 a -all" www.example.com. IN TXT "v=spf1 -all"
and this related bit, in the tip just above that:
Another reason to take HELO names into account has to do with Publish null SPF records for your domains that don't send mail. [link] Suppose you follow the advice in that FAQ but don't think about HELO names, you could inadvertently deny servers the right to send email. An example: a cloud of webservers send email forms out, using "webform@example.com" as the sender's address. Each webserver uses (as it should) its own name as the HELO parameter.
www.example.com. IN TXT "v=spf1 -all" web01.example.com. IN TXT "v=spf1 a -all" web02.example.com. IN TXT "v=spf1 a -all" web03.example.com. IN TXT "v=spf1 a -all"
and this related bit on separate page http://www.openspf.org/FAQ/One_record_for_each_domain :
Consider how spf works: when an spf aware mail server receives an incoming message it will request the spf record for the domain in the envelope from. If you only publish the spf record on somedomain.tld, and not on www.subdomain.tld, a forged message pretending from www.subdomain.tld will be happily accepted for lack of an spf record.
and this related bit on separate page http://www.openspf.org/FAQ/The_demon_question :
[Y]ou should add an SPF record for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF record, of the form: * IN TXT "v=spf1 -all"
Which, among other things, are very useful tips, but also highlighted my erroneous extrapolation.
There's much to learn from that page (er, those pages, but especially the 'Common mistakes' one), such as why my having 'a mx' in my SPF RR is also a (fairly harmless) mistake, because my A and MX records both resolve to the same IP, and because specifying it twice in the SPF RR is thus redundant, causing MTAs checking SPF to make multiple queries for no benefit:
List a server only once
Ultimately, SPF lookups resolve to an IP address. It is not necessary to list the same server using multiple host names (e.g., "example.com" and "www.example.com" which both resolve to the same IP). In fact doing so is a bit harder on your DNS servers since a receiving server progressing through your record may be forced to make multiple DNS lookups, when simply referencing the server hostname once would have been sufficient.
If the server's IP rarely changes, consider using the ip4:x.x.x.x (or ip6) notation so recipients can avoid DNS lookups entirely. Since there is a limit of 10 DNS lookups per SPF record, specifying an IP address or address range is preferable for long lists of outgoing mail servers.
Often an SPF record can be condensed down to something like v=spf1 ip4:x.x.x.x -all if there is only one outgoing mail server.
And that latter sentence is actually what I _ought_ to have my (current) SPF RR, the one for FDQN linuxmafia.com, be, given that mine is the limiting case where a single host with an unchanging IP is the sole source of all legitimate outbound mail.
Pursuant to the first tip, I will also consider adding SPF RRs for some of my prominent FQDNs that don't send mail. But only after careful additional thinking about SPF mechanics.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Well, notably at present, balug.org. and temp.balug.org. are pretty dang independent and unrelated. Until balug.org. (and lists.balug.org., etc.) are ripped out from under DreamHost.com. ...
{sigh} Here, let me hand it to you on a platter. We'll do through the whole zonefile.
These would be taken care of by a single SPF 'A' directive (if they send mail, which clearly most do not):
balug.org. IN A 208.97.176.67 archive.balug.org. IN A 198.144.194.238 www.balug.org. IN A 198.144.194.238 balug-sf-lug-v1.balug.org. IN A 198.144.194.238 balug-sf-lug-v2.balug.org. IN A 198.144.194.238 balug-untangle.balug.org. IN A 64.2.3.203 balug-sf-lug-v1.console.balug.org. IN A 208.96.15.250 balug-sf-lug-v2.console.balug.org. IN A 208.96.15.250 balug-untangle.console.balug.org. IN A 64.2.3.195 sf-lug-v1.console.balug.org. IN A 208.96.15.250 sf-lug-v2.console.balug.org. IN A 208.96.15.250 untangle.console.balug.org. IN A 64.2.3.195 ftp.balug.org. IN A 208.97.176.67 lists.balug.org. IN A 66.33.216.72 mail.balug.org. IN A 208.113.200.129 mailboxes.balug.org. IN A 66.33.205.233 www.mailboxes.balug.org. IN A 66.33.205.233 mysql.balug.org. IN A 208.97.161.83 ns1.balug.org. IN A 198.144.194.238 rsvp.balug.org. IN A 198.144.194.238 secure.balug.org. IN A 198.144.194.238 www.secure.balug.org. IN A 198.144.194.238 sf-lug.balug.org. IN A 208.96.15.252 www.sf-lug.balug.org. IN A 208.96.15.252 sf-lug-v1.balug.org. IN A 208.96.15.252 sf-lug-v2.balug.org. IN A 208.96.15.252 ssh.balug.org. IN A 208.97.176.67 untangle.balug.org. IN A 64.2.3.203 vicki.balug.org. IN A 208.96.15.250 webmail.balug.org. IN A 208.97.187.139 www.webmail.balug.org. IN A 208.97.187.139 webmaster.balug.org. IN A 198.144.194.238 wiki.balug.org. IN A 198.144.194.238 www.wiki.balug.org. IN A 198.144.194.238 www.balug.org. IN A 208.97.176.67 www0.balug.org. IN A 208.97.176.67 www1.balug.org. IN A 198.144.194.238 www2.balug.org. IN A 64.2.3.203
These two can be taken care of by a single SPF 'MX' directive:
mail.balug.org. IN MX 0 mx1.sub5.homie.mail.dreamhost.com. mail.balug.org. IN MX 0 mx2.sub5.homie.mail.dreamhost.com.
These can be taken care of by a single ipv6: directive if we're concerned about that.
ns1.balug.org. IN AAAA 2001:470:1f04:19e::2 rsvp.balug.org. IN AAAA 2001:470:1f04:19e::2 secure.balug.org. IN AAAA 2001:470:1f04:19e::2 www.secure.balug.org. IN AAAA 2001:470:1f04:19e::2 webmaster.balug.org. IN AAAA 2001:470:1f04:19e::2 wiki.balug.org. IN AAAA 2001:470:1f04:19e::2 www1.balug.org. IN AAAA 2001:470:1f04:19e::2 balug-sf-lug-v1.balug.org. IN AAAA 2001:470:1f04:19e::2 balug-sf-lug-v2.balug.org. IN AAAA 2001:470:1f04:19e::2
This can be taken care of by a single include: directive.
balug-dreamhost.balug.org. CNAME charles-carroll.dreamhost.com.
So, I make that to be:
balug.org. IN TXT "v=spf1 a mx ipv6:2001:470:1f04:19e::2 include:dreamhost.com -all"
That literally takes care of _every_ existing entry in the balug.org DNS that could possibly originate mail, plus every host that Dreamhost thinks might originate mail.
And, when you and Michael Hubbard give Dreamhost the heave-ho, all the need happen whenever convenient is removing the include: directive. (No hurry about that. No real harm if it remains.)
We should do it now. It's a one-line addition to DNS, and I've just handed you that line, already made.
Yes, effectively don't - or no guarantees it won't change. DreamHost does sometimes make changes to hostnames, IP addresses, etc., and with no notice of such changes - the only way I know about such changes is they show up in DNS, etc.
That's what the include: is for.
No assurances those correlate or will continue to correlate.
If Dreamhost doesn't know where it sends SMTP from, then we have a lot bigger problems.
Does their own mail fail their own SPF and get rejected as forgeries? No, I really don't think so. Then, their SPF record is a good enough statement of what they declare their SMTP hosts to be. Which, gosh, if they cannot get that right, they would be _really_ in the wrong line of business. But they demonstrably do get it right. Hallelujah.
Ah, now that makes sense. I mean why would DreamHost trust their own hosting after all? ;->
I assume it's because Dreamhost customers find it convenient to originate Dreamhost-hosted mail from Google, relay.mailchannels.net, and sendgrid.net -- and Dreamhost helps them by insuring that such outsourced mail-sending won't get rejected as forging dreamhost.com's envelope header.
Actually, if you look closely, they _did_ fsck up the first include: directive, the one for _spf.google.com. Which fortunately doesn't adversely affect us, because we don't try to originate balug.org outbound mail from Google.
BALUG-Admin mailing list BALUG-Admin@temp.balug.org https://temp.balug.org/cgi-bin/mailman/listinfo/balug-admin