[BALUG-Admin] BALUG & SPF
Rick Moen
rick@linuxmafia.com
Sat Aug 19 07:34:46 PDT 2017
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
More information about the BALUG-Admin
mailing list