[BALUG-Admin] BALUG & SPF ...
Michael Paoli
Michael.Paoli@cal.berkeley.edu
Sat Aug 19 23:47:37 PDT 2017
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.
More information about the BALUG-Admin
mailing list