SPF best practices?
After a rash of bounces that brought to my attention that my SPF record was not properly published, I rewrote my SPF record a bit. What I'm looking for is some insight on best practices and a second set of eyes, as my list hosts for addresses all over the internet.
The record is such:
v=spf1 ip4:206.225.172.6 a:bast.chez-vrolet.net a:chez-vrolet.net a:smtp.comcast.net ~all
This is published as a TXT record as per specification.
The a:smtp.comcast.net is necessary so I can send email remotely through my ISP and clear out successfully.
I'm a bit bothered by the '~all', however. I really don't want to do '-all' as I'm concerned that anybody who posts to the list would cause anybody on Yahoo or the MSFT owned domains (hotmail, live, etc.) to bounce again.
Anybody have any suggestions on how to make this happen *correctly*, or if there are any revisions I should make to my record?
-Dennis Carr
On Sun, Aug 23, 2015 at 2:42 AM, Dennis Carr <dennisthetiger@chez-vrolet.net> wrote:
Try this:
"v=spf1 mx a:comcast.net -all"
Or this:
"v=spf1 ip4:206.225.172.6 a:comcast.net -all"The first one is flexible over time, the 2nd one is more strict.
You do want -all, as Mailman sends from $list-bounces@domain.tld, not user@gmail.com
-Jim P.
Dennis Carr writes:
The a:smtp.comcast.net is necessary so I can send email remotely through my ISP and clear out successfully.
That does mean that anybody who can send through smtp.comcast.net can send as a mailbox from your domain and pass DMARC, most likely. I don't see a way to profitably exploit that offhand, though (unless you're a bank).
Executive summary: if you're sure you've got all your hosts covered by the SPF record, use -all as Jim P says.
Explanation: If you've got the SPF right, you *do* know all of the relevant hosts, and you've got them covered. Anybody else is spoofing your host at the transport level (*not* the From header), so deny them.
OTOH, your SPF has nothing to do with authentication of list posts from other domains. If your MTA and Mailman are configured correctly, both HELO and MAIL FROM defined by RFC 5321 will contain one of your domains (bast.chez-vrolet.net or chez-vrolet.net), and the last hop will be verified as coming from your domain using your SPF. This is regardless of the identity in From.
If the recipient participates in DMARC, and the message is From you, it will also pass DMARC. (Effectively; the details are nitpicky.)
If the recipient participates in the DMARC protocol, and you resend a post from a third party, the recipient will *also* check the SPF for the domain in the RFC 5322 From field, and it will fail. There is no change you can make to your SPF record that can change this; it's the remote domain's SPF record that matters.
This is why DMARC specifies that a valid DKIM signature by the domain in From is also a pass. SPF is absolutely useless except for "direct to recipient" messages (strictly speaking, sender's MX to recipient's MX, it might bounce around a bit inside each domain). Of course such direct mail is a large fraction of mail on the Internet nowadays, so it's a very useful exception in general.
Unfortunately, public discussion mailing lists can't take advantage of that exception.
HTH,
Steve
On 08/23/2015 08:13 AM, Stephen J. Turnbull wrote:
Executive summary: if you're sure you've got all your hosts covered by the SPF record, use -all as Jim P says.
There is an issue with -all. SPF does not work with .forwards or other relaying of that nature. If you can be certain that every recipient's final MX is the one your server sends to, then -all is OK, but you can't.
The scenario is your list member is user@example.com. user@example.com is set to forward all mail to example_user@yahoo.com. Yahoo receives the list post with envelope from listname-bounces@your.list.server (or listname-bounces+user=example.com@your.list.server if VERPed) for example_user@yahoo.com from the server at example.com. The SPF for your.list.server doesn't allow example.com as a relay, so SPF fails at yahoo.com.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
True enough.
Note: If I took that argument seriously, I'd use ?all, not ~all, though. According to RFC 4408, you shouldn't reject a message only because of an SPF softfail, but it's not neutral, either. Mail will be lost if you use ~all, just not as much.
The scenario is your list member is user@example.com. user@example.com is set to forward all mail to example_user@yahoo.com.
Heh. This user is screwed if you use dmarc_moderation_action too.
Bottom line: Friends don't let friends use Yahoo! or AOL.
On 08/23/2015 10:59 AM, Stephen J. Turnbull wrote:
I don't think so. The munged From: will be from the list's domain which probably doesn't publish a DMARC policy, but even if it does, it *should* also be DKIM signing the outgoing mail.
The forward shouldn't alter the message in ways that break the list server's DKIM sig so at the ultimate receiving end the message has a valid DKIM sig that aligns with the From: domain.
Bottom line: Friends don't let friends use Yahoo! or AOL.
+1
As an aside, perhaps a more telling example of how SPF is broken is the following. example.com publishes an SPF with '-all'. user@example.com sends a message to postmaster@python.org which is an alias for a few people's addresses on other hosts. If all those end recipients check SPF they may reject the message with envelope from user@example.com because it comes from a server at mail.python.org which isn't allowed to send mail with envelope from the example.com domain.
You can never know if any of your intended recipient addresses pass through such a relay, thus my opinion is if you're concerned about your mail being delivered, you can't use SPF -all.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
I was thinking about the opposite case, where it *doesn't* get munged. Temporary brain fart -- that is OK because the *From* domain can't be p=reject, so no problem with DMARC even though Yahoo! has draconian policies. (Of course the user must deal with rejects due to Yahoo!'s AUP, but that doesn't have anything to do with DMARC.)
This stuff is just hard to think about. :-(
On Sun, Aug 23, 2015 at 2:42 AM, Dennis Carr <dennisthetiger@chez-vrolet.net> wrote:
Try this:
"v=spf1 mx a:comcast.net -all"
Or this:
"v=spf1 ip4:206.225.172.6 a:comcast.net -all"The first one is flexible over time, the 2nd one is more strict.
You do want -all, as Mailman sends from $list-bounces@domain.tld, not user@gmail.com
-Jim P.
Dennis Carr writes:
The a:smtp.comcast.net is necessary so I can send email remotely through my ISP and clear out successfully.
That does mean that anybody who can send through smtp.comcast.net can send as a mailbox from your domain and pass DMARC, most likely. I don't see a way to profitably exploit that offhand, though (unless you're a bank).
Executive summary: if you're sure you've got all your hosts covered by the SPF record, use -all as Jim P says.
Explanation: If you've got the SPF right, you *do* know all of the relevant hosts, and you've got them covered. Anybody else is spoofing your host at the transport level (*not* the From header), so deny them.
OTOH, your SPF has nothing to do with authentication of list posts from other domains. If your MTA and Mailman are configured correctly, both HELO and MAIL FROM defined by RFC 5321 will contain one of your domains (bast.chez-vrolet.net or chez-vrolet.net), and the last hop will be verified as coming from your domain using your SPF. This is regardless of the identity in From.
If the recipient participates in DMARC, and the message is From you, it will also pass DMARC. (Effectively; the details are nitpicky.)
If the recipient participates in the DMARC protocol, and you resend a post from a third party, the recipient will *also* check the SPF for the domain in the RFC 5322 From field, and it will fail. There is no change you can make to your SPF record that can change this; it's the remote domain's SPF record that matters.
This is why DMARC specifies that a valid DKIM signature by the domain in From is also a pass. SPF is absolutely useless except for "direct to recipient" messages (strictly speaking, sender's MX to recipient's MX, it might bounce around a bit inside each domain). Of course such direct mail is a large fraction of mail on the Internet nowadays, so it's a very useful exception in general.
Unfortunately, public discussion mailing lists can't take advantage of that exception.
HTH,
Steve
On 08/23/2015 08:13 AM, Stephen J. Turnbull wrote:
Executive summary: if you're sure you've got all your hosts covered by the SPF record, use -all as Jim P says.
There is an issue with -all. SPF does not work with .forwards or other relaying of that nature. If you can be certain that every recipient's final MX is the one your server sends to, then -all is OK, but you can't.
The scenario is your list member is user@example.com. user@example.com is set to forward all mail to example_user@yahoo.com. Yahoo receives the list post with envelope from listname-bounces@your.list.server (or listname-bounces+user=example.com@your.list.server if VERPed) for example_user@yahoo.com from the server at example.com. The SPF for your.list.server doesn't allow example.com as a relay, so SPF fails at yahoo.com.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
True enough.
Note: If I took that argument seriously, I'd use ?all, not ~all, though. According to RFC 4408, you shouldn't reject a message only because of an SPF softfail, but it's not neutral, either. Mail will be lost if you use ~all, just not as much.
The scenario is your list member is user@example.com. user@example.com is set to forward all mail to example_user@yahoo.com.
Heh. This user is screwed if you use dmarc_moderation_action too.
Bottom line: Friends don't let friends use Yahoo! or AOL.
On 08/23/2015 10:59 AM, Stephen J. Turnbull wrote:
I don't think so. The munged From: will be from the list's domain which probably doesn't publish a DMARC policy, but even if it does, it *should* also be DKIM signing the outgoing mail.
The forward shouldn't alter the message in ways that break the list server's DKIM sig so at the ultimate receiving end the message has a valid DKIM sig that aligns with the From: domain.
Bottom line: Friends don't let friends use Yahoo! or AOL.
+1
As an aside, perhaps a more telling example of how SPF is broken is the following. example.com publishes an SPF with '-all'. user@example.com sends a message to postmaster@python.org which is an alias for a few people's addresses on other hosts. If all those end recipients check SPF they may reject the message with envelope from user@example.com because it comes from a server at mail.python.org which isn't allowed to send mail with envelope from the example.com domain.
You can never know if any of your intended recipient addresses pass through such a relay, thus my opinion is if you're concerned about your mail being delivered, you can't use SPF -all.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
I was thinking about the opposite case, where it *doesn't* get munged. Temporary brain fart -- that is OK because the *From* domain can't be p=reject, so no problem with DMARC even though Yahoo! has draconian policies. (Of course the user must deal with rejects due to Yahoo!'s AUP, but that doesn't have anything to do with DMARC.)
This stuff is just hard to think about. :-(
participants (4)
-
Dennis Carr -
Jim Popovitch -
Mark Sapiro -
Stephen J. Turnbull