[adding balug-admin]
Quoting Glen Martin (glen@glen-martin.com):
I expect the alterations are the insertion of a list footer in the message text. I expect similar insertion in the Subject header to be problematic as well, though this DMARC didn't complain of that.
My understanding is that the sending domain's DKIM policy (portion of DMARC) declares which headers and text portions are attested by cryptographic signing. Failing the DKIM aspect of DMARC means the forwarder host (in this case the MLM host) has altered or inserted into one of the signed areas of the message, and not stripped the DKIM headers. (Some listadmins strip such headers as a way of avoiding the perception of DMARC failure upon retransmission. I'm not sure this is wise. Seems like there might be adverse consequences.)
Here's a header from one of my own messages to the list, having come back to me through the list and evaluated using my own inbound testers (opendmarc and opendkim). The two "Authentication-results:" headers are the problem. For help understanding the headers, I'll point out that my primary domain on this MX is locutory.org, hence that name in the headers.
Downthread in that offlist conversation with Michael, I notice you said:
However, glen-martin.com publishes authorized sending hosts (in SPF), and temp.balug.org (or any other balug.org) isn't on that list. Strike 1.
To the best of my understanding, MLM retransmission of messages to subscribers is _not_ going to violate any sender's SPF policy, because the retransmitted message to each subscriber bears a new, different envelope citing the MLM's domain. Hence, on that retransmission, the relevant SPF record that would be consulted upon arrival at the subscriber's MTA is not the poster's domain but rather the MLM's (balug.org's).
The example test mail to balug-talk whose full headers you sent to Michael had, as received by you as subscriber:
Received-SPF: pass (glen-martin.com: 50.196.148.122 is authorized to use 'glen@glen-martin.com' in 'mfrom' identity (mechanism 'ip4:50.196.148.122' matched) (glen-martin.com: 50.196.148.122 is authorized to use 'glen@glen-martin.com' in 'mfrom' identity (mechanism 'ip4:50.196.148.122' matched)))
If I'm reading that right, temp.balug.org's (IP 198.144.194.238's) MTA software inserted that when it received your original posting, and temp.balug.org considered all to be well at that point, as 50.196.148.122 was one of the declared authorised senders in your domain's SPF RR.
temp.balug.org then turned around and retransmitted a fresh copy to each balug-talk subscriber including, of course, you. It bore a totally new SMTP envelope, for which the envelope sender was:
Return-Path: balug-talk-bounces@temp.balug.org
So, your receiving MTA, getting the subscriber copy, would have sought to vet transmitting MTA IP 198.144.194.238 (temp.balug.org) against the SPF RR not of _your_ domain (for that copy), but rather of domain balug.org.
People get really confused about SPF and mailing list, I notice, forgetting that the MLM's forward is a separate message with a different SMTP envelope (from a different domain).
Let's look at the balug.org SPF RR:
:r! dig -t txt balug.org +short [null return value]
Well, Michael, time to put an SPF RR in the balug.org DNS. This one works for my domain:
:r! dig -t txt linuxmafia.com +short "v=spf1 a mx -all"
Any questions, please just ask. It says 'use version 1 of SPF protocol, consider the received mail legitimate if it arrives from an IP corresponding with the linuxmafia.com A or MX RR, and please hardfail as a forgery any message purporting to come from linuxmafia.com arriving from any _other_ IP.'
Authentication-Results: mail2.locutory.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=glen-martin.com
Well, could you please compare the message body as you sent it with the message body as you received it in the retransmitted subscriber copy, and tell us what you signed that got changed?
What I'm saying is that it's unclear on this end what is the scope of your domain's DKIM cryptographic scrutiny. OK, the 'body has been altered', but what specifically does that mean? Is your domain's DKIM policy so twitchy that Mailman merely adding a Mailman footer breaks it? Does Mailman adding List-Id, List-Subscribe, List-Help, and List-Unsubscribe headers break it? You define and control that DKIM policy for your domain, so perhaps you can tell us.
Balug is also inserting headers/footers into Subject and Body, so the DKIM checksum fails (message is modified). Strike 2.
You cannot expect Mailman mailing lists to _not_ add additional SMTP headers, add a footer, and insert a Subject header tag (like '[BALUG-Talk]'), so it seems to me your DKIM policy ought _not_ to be set to fail if such things are changed by standards-compliant forwarders such as MLMs. Those are things that mailing lists _must_ do in some cases, and traditionally do for excellent reasons (like adding a footer) in others.
If you expect mailing lists to not do normal mailing list things, then I submit that IMO your domain's DKIM policy is broken and urgently needs revision.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: BALUG-Talk and SPF/DKIM Date: Fri, 18 Aug 2017 05:49:07 -0700
So, your receiving MTA, getting the subscriber copy, would have sought to vet transmitting MTA IP 198.144.194.238 (temp.balug.org) against the SPF RR not of _your_ domain (for that copy), but rather of domain balug.org.
People get really confused about SPF and mailing list, I notice, forgetting that the MLM's forward is a separate message with a different SMTP envelope (from a different domain).
Let's look at the balug.org SPF RR:
:r! dig -t txt balug.org +short [null return value]
Well, Michael, time to put an SPF RR in the balug.org DNS.
Well, much of the migration criteria has been "not worse than". https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists ... much to be improved, but fair bit of that will come later. First of all, for the lists, the sending domain is temp.balug.org, not balug.org. And for the old list hosting location, lists.balug.org. Note that there are no SPF(/TXT) records for lists.balug.org. And so it is thus far for temp.balug.org. Yes, certainly not ideal, but "good enough" for the time being. Will probably add the SPF & TXT records to lists.balug.org. once that gets moved over. The canonical will shift back to lists.balug.org - but that will happen *after* it's moved over. Likewise for @balug.org ... "not worse than" criteria ... will deal with further improving it after it's moved over. Also, for a lot of such stuff, before it's moved over, trying to "fix"/improve is about double (or more) work, as it has to be done in two places. And since I can't control all of what DreamHost.com does, making some changes there also risks possibly causing severe breakage (e.g. if I add SPF for balug.org, and it then conflicts with some change they make, then that breaks balug.org SPF).
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Well, much of the migration criteria has been "not worse than". https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists ... much to be improved, but fair bit of that will come later. First of all, for the lists, the sending domain is temp.balug.org, not balug.org.
I see no reason why you couldn't declare an SPF RR for a subdomain. I've just never to date had a need to do so, on my systems.
If you need to say 'trust the A host, the MX host, and this list of additional IPs', that can be done trivially, too. From memory, you include something like 'ipv4:66.33.216.72'.
Frankly, I'd not bother declaring specific SPF RRs for subdomains. KISS. Have a single txt record for the domain, and just put everything in it that is necessary to include all SMTP senders you wish to authorise, including both mailing list locations.
It's really not difficult.
Will probably add the SPF & TXT records to lists.balug.org. once that gets moved over.
No, for the love of ghod, no.
First of all, nobody uses the dedicated SPF RR. Everyone uses TXT. The dedicated RR was a nonstarter.
Second, you don't need friggin' multiple records. Just the one. And there's no conceivable reason not to do it now.
I mean, why delay? Are you saying we don't know what the authorised sending SMTP hosts are (the ones we want to declare authorised) for domain balug.org? Is it a mystery? (Note: Hypothetical Dreamhost changes are addressed below.) Is there some presently unknown MTA in the South Seas that we wish to be able to believably forge balug.org as a sending domain going forward?
No? Then we should have an SPF RR for the domain. Now.
Add one line to the zonefile, roll the S/N, reload the zone, done.
Also, for a lot of such stuff, before it's moved over, trying to "fix"/improve is about double (or more) work, as it has to be done in two places.
And since I can't control all of what DreamHost.com does, making some changes there also risks possibly causing severe breakage.
No, it doesn't. If you're worried about Dreamhost suddenly and in the near futher moving where its authorised SMTP sender is for lists.balug.org to a new IP, you can use the SPF RR "include" directive to incorporate _their_ SPF RR by reference.
include:dreamhost.com
http://www.openspf.org/SPF_Record_Syntax
And yes, I did check to verify that they have such an RR.
:r! dig -t txt dreamhost.com +short "MS=ms82701515" "v=spf1 ip4:62.229.62.0/24 ip4:69.64.144.0/20 ip4:98.124.192.0/18 ip4:66.33.206.0/24 ip4:66.33.195.34 ip4:208.113.189.254 ip4:208.113.200.0/24 ip4:66.33.216.0/24 ip4:208.97.187.128/25 ip4:64.90.62.0/24 ip4:64.90.63.0/25 ip4:64.90.63.128/26 include:_spf.goo" "gle.com include:relay.mailchannels.net include:sendgrid.net ~ALL"
Notice that they use include options so they can authorise several external senders whose DNS and IP assignments are not under their control.
C'mon, Michael. Sheesh. ;->
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] BALUG & SPF Date: Fri, 18 Aug 2017 06:47:28 -0700
I see no reason why you couldn't declare an SPF RR for a subdomain. I've just never to date had a need to do so, on my systems.
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. ...
KISS. Have a single txt record for the domain, and just put everything
"Things should be as simple as possible, but no simpler" ;-) A lot of the DNS that *will* get moved over, is mostly set up to initially do a one-to-one mapping - that makes dealing with it in the interim about as simple as feasible, and I'm trying to avoid complicating that by adding stuff now, that can about as well or better (and notably more simply and less confusing, and less differences to need to be aware and keep track of) be added later (but hey, also, later should arrive *fairly* soon). Also, getting the heck off of DreamHost.com has priority over less critical stuff that can be improved later.
I mean, why delay? Are you saying we don't know what the authorised sending SMTP hosts are (the ones we want to declare authorised) for domain balug.org? Is it a mystery? (Note: Hypothetical Dreamhost
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. As for DreamHost.com hosting, the sending domains are @balug.org and (for the lists) @lists.balug.org, but we don't control the IPs, MX records, etc. used by those. So, yeah, might be able to drop SPF record(s) in there, but could also thorughly screw things over too - and at any point in time and with no advance notice (and DreamHost.com might not let us add or alter some of those DNS records anyway, and DNS changes on DreamHost.com. are quite a PITA anyway).
No, it doesn't. If you're worried about Dreamhost suddenly and in the near futher moving where its authorised SMTP sender is for lists.balug.org to a new IP, you can use the SPF RR "include" directive to incorporate _their_ SPF RR by reference.
No assurances those correlate or will continue to correlate.
Notice that they use include options so they can authorise several external senders whose DNS and IP assignments are not under their control.
Ah, now that makes sense. I mean why would DreamHost trust their own hosting after all? ;->
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.
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
Thanks for the updates/corrections. :-) Yeah, I kind'a suspected you might'a been a bit fatigued or something, or forgotten some of the details of exactly the situation BALUG has been in and still is regarding DNS & DreamHost.com ... but *fairly* soon that should change and be *much* better! :-)
Just a few more hoops to jump through (egad .. have to get primary account holder to open ticket to get the dang raw mbox archives) ... but *soon* ...
And good point also about using SPF to effectively say "this domain never originates email, hard fail anything that claims to be from such" for relevant (sub)domain(s). And as you also point out, yes, should review for which names/(sub-)domains that ought be applied (I forget and may not be current on exactly what best practice is for which (sub)domains/names it ought be done, and for which it's better to *not* add the SPF records). Anyway, I'd kind'a forgotten about that point. 8-O
And ... type SPF & TXT, or ... just TXT or just SPF? Yeah, I'm curious about current status on that ... I know from years ago where it was *theoretically* headed. Also could potentially do the experiment at some point - have SPF and TXT RR types with SPF data, and ... do some DNS query logging. If most MTAs check SPF first, and if they find something there, don't then check for TXT ... then probably good to (also) have type SPF RR. Need TXT for backwards compatibility at least for older MTAs and such. And, if most all of 'em don't even bother to check for type SPF, or do that and then check for TXT anyway even if SPF is found ... then not a lot of point to have type SPF. And could potentially do the experiment (heck, even without adding type SPF, see what the queries are) - could run it relatively briefly ... just before BALUG-announce email goes out should generate some fair bit of DNS queries for SPF related data.
And yes, I'm pretty dang familiar with SPF ... though I've not worked with it extensively for several years now ... so some things may have changed slightly/moderately. It is a pretty nice and flexible thing. Also good, where feasible, to do A record(s) in the SPF data (and as I recall, it can do blocks/ranges too, among listed address(es)). Doing so (A and/or AAAA data) avoids additional DNS lookups ... but sometimes that's not feasible, and one uses a different mechanism (e.g. MX referral, if, for example, the sending sources always correlate to the MX records, but the MX records may not correlate to particularly static IPs). And yep, haven't yet had occasion to do IPv6 IPs in SPF data - so I'll need to go over that to ... though we're not yet sending out via IPv6 - but are receiving also via IPv6 ... sending also via IPv6 comes wee bit later.
And as for domains, BALUG only uses 3 for sending: @lists.balug.org (was and will again be lists) @temp.balug.org (temporarily covering above functionality) @balug (mostly just some alias goop) That's it, nothin' else from in/under domain balug.org.
Should probably also (re)visit SF-LUG.org and SF-LUG.com at some point - but that would be discussion for another list (we've touched on it in past, but it's been a while ... and SF-LUG.com would be a never sends from domain). About the only relevant tie-in between that and BALUG is ... common host ... but that discussion thereof belongs on SF-LUG list. And now that there's MTA on the host configured to actually be able to send to and receive from The Internet, it starts to become a more relevant question again.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] BALUG & SPF Date: Sat, 19 Aug 2017 07:34:46 -0700
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.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Thanks for the updates/corrections. :-) Yeah, I kind'a suspected you might'a been a bit fatigued or something, or forgotten some of the details of exactly the situation BALUG has been in and still is regarding DNS & DreamHost.com ... but *fairly* soon that should change and be *much* better! :-)
That was part of it, and the other part was that I implemented SPF ages ago (2010, I think) on linuxmafia.com for that domain's very mimimal needs and simple situation -- and over the years since became fuzzy about the mechanics of that standard, simply overextrapolated its application to subdomains, whereas by intention an SPF RR's effect does _not_ flow down automatically to subdomains [/hosts] of a base domain.
And good point also about using SPF to effectively say "this domain never originates email, hard fail anything that claims to be from such" for relevant (sub)domain(s).
Which brings me to the point of this mail: I just now implemented that, and herewith present my current zonefile, as revised:
:r /etc/bind/linuxmafia.com.zone
$TTL 86400 $ORIGIN linuxmafia.com. @ IN SOA ns1.linuxmafia.com. rick.deirdre.net. ( 2017082101 ; serial 7200 ; refresh 2 hours 3600 ; retry 1 hour 2419200 ; expire 28 days 900 ; negative TTL 15 mins ) ; IN NS ns1.linuxmafia.com. IN NS ns3.linuxmafia.com. IN NS ns1.thecoop.net. IN NS ns.primate.net. IN NS ns.tx.primate.net. IN A 198.144.195.186 IN MX 10 linuxmafia.com. IN HINFO P3/500 Linux-v.2.4.24 IN TXT "v=spf1 ipv4:198.144.195.186 -all" LOC 37 25 53.825 N 122 11 52.128 W 15m uncle-enzo IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" enzo IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" mail IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" www IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ftp IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ns1 IN A 198.144.195.186 IN MX 10 linuxmafia.com. LOC 37 25 53.825 N 122 11 52.128 W 15m ns3 IN A 198.144.209.73 IN TXT "v=spf1 -all" ; ns3 is aka ns.catwhisker.org, David Wolfskill's box water IN A 198.144.195.188 IN TXT "v=spf1 -all" wap IN A 198.144.195.187 IN TXT "v=spf1 -all" nsa IN CNAME bxa.doc.gov. sf-lug IN A 198.144.194.238 IN TXT "v=spf1 -all"
Yes, I still use BIND9, though I disrecommend it. For all new authoritative nameservers, I recommend NSD. For all new recursive nameservers, I recommend Unbound. (For very large sites, the two corresponding packages of the PowerDNS suite are often better, if you don't mind dealing with databases.)
A few points about style and content: I add comment lines where absolutely essential for clarity and in one place (after the SOA) for spacing. The $ORIGIN line is not actually needed and present in my zonefiles merely as syntactic sugar, so that you can see at a glance what zonefile you're in. Woe betide you putting the _wrong_ $ORIGIN in a zonefile via copying an old zonefile to create a new one and forgetting to change that line. I might be better off on balance using a comment line instead.
The alias 'ns3.linuxmafia.com' for David Wolfskill's ns.catwhisker.org is a fine point of DNS performance. It's about bailiwick. Any recursive nameserver asking about linuxmafia.com's NS record will get the answer to those queries plus 'ADDITIONAL SECTION' glue-record answers not specifically requested stating the corresponding 'A' records for the NS ones -- but only when the request is inside the bailiwick of the TLD nameserver giving the answer. com. is outside org.'s bailiwick. Therefore, giving David's org. nameserver an alias within com. and using that saves lookups.
At the time I did that, the same TLD nameservers handled both com. and net., so glue records for ns1.thecoop.net, ns.primate.net, and ns.tx.primate.net were returned on 'ns' queries about linuxmafia.com . In checking today, I see something must have changed, as that is no longer true:
~ $ dig -t ns linuxmafia.com @ns1.linuxmafia.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34722 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2
;; ANSWER SECTION: linuxmafia.com. 86400 IN NS ns.primate.net. linuxmafia.com. 86400 IN NS ns.tx.primate.net. linuxmafia.com. 86400 IN NS ns1.thecoop.net. linuxmafia.com. 86400 IN NS ns3.linuxmafia.com. linuxmafia.com. 86400 IN NS ns1.linuxmafia.com.
;; ADDITIONAL SECTION: ns1.linuxmafia.com. 86400 IN A 198.144.195.186 ns3.linuxmafia.com. 86400 IN A 198.144.209.73
[rick@linuxmafia] ~ $
As a later date, I will probably alias those three as ns2.linuxmafia.com, ns4.linuxmafia.com, and ns5.linuxmafia.com, so that automatic glue record delivery for those will happen again, and nameservers querying my five NS (auth nameserver) lines in-zone will no longer then have to turn right around and do separate 'A' record lookups for three of them before being able to use the 'NS' answers.
(In case you're curious, there used to be an ns2.linuxmafia.com, pointing to David's old IP for ns.catwhisker.org. He notified me of its pending replacement with a new IP so I listed the new one as ns3, then eventually removed the vestigial ns2 entry when that IP went away.)
All of the SOA subfield values and the global $TTL value are squarely inside RFC-recommendation ranges. People very, very often get those wrong, whcih is one reason why since the 1990s I've published my zonefile and BIND9 conffiles as a downloadable tarball, to help people have a model to follow if they wish.
The 'rick.deirdre.net' of course means 'rick@deirdre.net' as an SMTP mailbox, and is the public point of contact in case people need to inquire with the zonefile maintainer. Note that it is carefully out-of-band for the domain (and indeed for the host handling my mail), routed to my wife Deirdre's domain. Ensuring out-of-band contact is another thing people often screw up, both here and in domain whois contacts. It's a bit sad when you cannot be told 'Dude, there's a problem with your zonefile [/domain]' because there's a problem with your zonefile [/domain].
Note that there are five auth nameservers. RFC-2182 section 5 recommends minimum 3, maximum 7. Mine are network-diverse and across different portions of the national power grid, e.g., at least one of the primate.net ones is in Texas. (Why? Because avoiding SPoFs is at least as important a principle as ensuring out-of-band reachability about problems with the things in question.)
The HINFO (host info) and LOC (location) records are because why not? The HINFO record's kernel declaration is now intentionally misleading, though, because I've become wary of advertising certain version information -- including also nameserver details queried from the abstract CHAOS class:
:r /etc/named/named.conf.options
options { [...] version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; //server-id is essentially redundant to hostname, default is none //server-id none; [...] }; [...]
The LOC data is a completely accurate set of longitude, latitude, and altitude specs. Some people go out of their way to hide. I go out of my way to ostentatiously _not_ hide, because I'll be damned if I obscure where in the world I live and compute. I call it my 'ICBM address', and it also appears in human-readable form on my personal Web page.
water.linuxmafia.com is my OpenSprinkler Arduino device controlling the drip irrigation and lawn watering for my property. It has an admin WebUI. (No, I'm not giving out the access password.)
wap.linuxmafia.com is my LinkSys wrt54g WAP running OpenWRT, powered on only during CABAL meetings.
Notice that nsa.linuxmafia.com is my _only_ CNAME record. Newcomers to DNS tend to horribly overuse the CNAME RR and for bad reasons, creating long-term problems for themselves. My rule of thumb is to _never_ use a CNAME for intra-zone references. That use-case and can should be an 'A' record, instead -- saving double-lookups and avoiding future maintenance errors.
What is nsa.linuxmafia.com for? In 2000, when the Federal government semi-gracefully surrendered to Daniel J. Bernstein's ongoing lawsuit asserting the right to export strong crypto, a new Commerce Department Export Administration Regulations (EAR) rulemaking suddenly permitted the strong-crypto export that existed anyway, but required any USA Internet sites intending to offer strong-crypto for export to notify Commerce Department Bureau of Export Administration at crypt@bxa.doc.gov . My alias was on the one hand a convenience so I didn't have to remember 'bxa.doc.gov' and could just e-mail crypt@linuxmafia.com, and on the other hand also a small joke about Federal stupidity.
(Reference: https://epic.org/crypto/export_controls/regs_1_00.html I have no idea if that EAR is still theoretically in force, but FWIW I only ever sent the one 'Hey, linuxmafia.com is offering strong crypto for public ftp and Web access, bye!" mail, which was all that was to my knowledge ever required.)
sf-lug.linuxmafia.com is of course the BALUG/SF-LUG Web host. I believe I created that RR at a time, long ago, when SF-LUG's DNS was on the fritz. Normally, that would be a CNAME, being cross-domain. I probably should lose it.
And last, of course, you will note that every 'A' DNS reference record (RR) that is _not_ my outgoing mail server now has an accompanying SPF RR saying 'this FQDN never originates mail, so please consider any mail claiming to come from it forged.'
And ... type SPF & TXT, or ... just TXT or just SPF? Yeah, I'm curious about current status on that ...
The dedicated SPF RR does exist as an IETF spec. Among the problems with it is that, if one of your slave auth nameservers runs nameserver software, that doesn't know how to handle a dedicated SPF RR encounters it, or a recursive software package unable to handle one receives it, then you could have problems, whereas any nameserver will correctly onvey as literal text a TXT record. And, of course, MTAs if they check SPF at all will know to query TXT, but it's less likely that they'll know to check dedicated SPF RRs.
So, the smart money say, just use TXT. Adding a decicated SPF RR if you already have a TXT one buys you nothing[1] and exposes you to potential problems from (at least) slave nameservers that might not know how to handle one. So, no obvious gain, possible downside, don't bother.
The above perception being widely held among DNS maintainers has further discouraged use of the dedicated SPF RR, creating a vicious cycle against it.
[1] You might say 'prevents the need for an MTA / MTA-helper to do two lookups'. I'll believe that when I see evidence of such software checking SPF RR first and then falling back to TXT.
I wrote:
The dedicated SPF RR does exist as an IETF spec.
Update: Discontinued in 2014 -- and I would suggest this was probably because of the considerations I cited. Reference: https://tools.ietf.org/html/rfc7208#section-3.1 https://tools.ietf.org/html/rfc6686#appendix-A
Quoting the former:
SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.
In 2003, when SPF was first being developed, the requirements for assignment of a new DNS RR type were considerably more stringent than they are now. Additionally, support for easy deployment of new DNS RR types was not widely deployed in DNS servers and provisioning systems. As a result, developers of SPF found it easier and more practical to use the TXT RR type for SPF records.
In its review of [RFC4408], the SPFbis working group concluded that its dual RR type transition model was fundamentally flawed since it contained no common RR type that implementers were required to serve and required to check. Many alternatives were considered to resolve this issue, but ultimately the working group concluded that significant migration to the SPF RR type in the foreseeable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type from SPF version 1. See Appendix A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deployment a decade ago are unique. If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers. Further discussion of design considerations when using new DNS RR types can be found in [RFC5507].
Which also prompts a correction to my earlier post: I'm pretty sure I added my SPF RR immediately upon Meng Wong finishing the SPF spec in 2003, and not in 2010 as I said earlier.
I wrote:
IN A 198.144.195.186 IN MX 10 linuxmafia.com. IN HINFO P3/500 Linux-v.2.4.24 IN TXT "v=spf1 ipv4:198.144.195.186 -all"
^^^^
LOC 37 25 53.825 N 122 11 52.128 W 15m
_And_, I screwed this up -- having arrogantly not bothered to double-check SPF TXT RR syntax before writing the RHS string, and instead doing it from memory. Correct version:
IN TXT "v=spf1 ip4:198.144.195.186 -all"
Note (correct) 'ip4', vice (incorrect) 'ipv4'.
That'll teach me to skip the all-important 'verify your work' step. Fortunately, the RR wasn't incorrect (invalid syntax) for very long.
Useful tool: Send an e-mail to check-auth@verifier.port25.com and you will receive a reply containing the results of an SPF check.
The similar tool that used to be available at spf-test@openspf.net has been discontinued.
Further cleaned-up. I think it's _really_ important that zonefiles on the master servers be formatted so as to be optimally legible, because otherwise it's really difficult to spot errors and things needing updating.
$TTL 86400 $ORIGIN linuxmafia.com. @ IN SOA ns1.linuxmafia.com. rick.deirdre.net. ( 2017082106 ; serial 7200 ; refresh 2 hours 3600 ; retry 1 hour 2419200 ; expire 28 days 900 ; negative TTL 15 mins ) ; IN NS ns1.linuxmafia.com. IN NS ns3.linuxmafia.com. IN NS ns1.thecoop.net. IN NS ns.primate.net. IN NS ns.tx.primate.net. IN A 198.144.195.186 IN MX 10 linuxmafia.com. IN HINFO P3/500 Linux IN TXT "v=spf1 ip4:198.144.195.186 -all" LOC 37 25 53.825 N 122 11 52.128 W 15m ; uncle-enzo IN A 198.144.195.186 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ; enzo IN A 198.144.195.186 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ; mail IN A 198.144.195.186 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ; www IN A 198.144.195.186 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ; ftp IN A 198.144.195.186 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ; ns1 IN A 198.144.195.186 IN MX 10 linuxmafia.com. IN LOC 37 25 53.825 N 122 11 52.128 W 15m ; ns3 IN A 198.144.209.73 IN TXT "v=spf1 -all" ; ns3 is aka ns.catwhisker.org, David Wolfskill's box ; water IN A 198.144.195.188 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN HINFO Arduino OpenSprinkler IN TXT "v=spf1 -all" ; wap IN A 198.144.195.187 IN LOC 37 25 53.825 N 122 11 52.128 W 15m IN HINFO LinkSys-WRT54G-v3 OpenWRT IN TXT "v=spf1 -all" ; nsa IN CNAME bxa.doc.gov.