3 ms·

The article explains that the topic is hotly debated, even controversial maybe. But everything that you are pointing out here has been addressed in the article.

by LeonM 4y ago

The article explains that the topic is hotly debated, even controversial maybe. But everything that you are pointing out here has been addressed in the article. > If relaying is happening, and you haven't added the relay to your SPF, then you're wrong. There is no scenario where this is problem with SPF. That is the problem, you do not control whether your email is being relayed. This does not happen on your side, it happens on the receiver's side. You cannot control that. > Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF. That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation. This is why you don't want to rely on SPF, and focus on DKIM instead. > These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly. Without DMARC, SPF offers no security at all. None. This is due the bypass vulnerability. If you adopt DMARC (which you should!) then 'hard' fail and softfail become equal from a security perspective. With DMARC, anything that is not an aligned SPF pass is a fail. Even if a 'superduperultrafail' would exist, it would do the exact same thing as softfail. But because SPF is so unreliable, you shouldn't rely on it in the first place. Focus on DKIM and DMARC. Leave SPF on softfail, which does the exact same thing as 'hard' fail, without the deliverability issues.

johnklos 4y ago
I don't understand this. First you're talking about forwarding / relaying you don't control, which... you shouldn't care about. If someone else wants to forward / relay, then they need to worry about SPF breakage. You don't, nor should you. Then, you're talking about something entirely different: "That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation." Huh? No. If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong. Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all. Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.
- LeonM 4y ago
  For DMARC, you need SPF or DKIM to be aligned for the email to be accepted. One of the two is enough for the receiver to accept the email based on DMARC. This is how DMARC is designed, I can't change that. You can have an SPF fail but aligned DKIM, the email will be accepted. You can have SPF alignment without a DKIM signature, and still be accepted. If you have neither, the email will be rejected. This was all designed with backwards compatibility in mind. This was back in the days that not every email service was capable of signing with DKIM, so for those you could still use SPF. However, it was already widely accepted back then that SPF was very much broken by design, and you should use DKIM instead (but keep SPF for backwards compatibility). DKIM is much better in terms of security (it uses actual cryptography) and reliability (much less likely to break beyond your control). If your email services support DKIM, you should use that. > If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong. DKIM is able to disagree with SPF, that's how DMARC is designed. If you an email has a valid signature, but not valid SPF, your email should still be accepted. > Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all. It think you are missing something. You can set a '-all' policy, but then you risk making you own perfectly authentic and DKIM signed email undeliverable. You cannot rely on SPF to pass, even if you have the sender set up correctly in the SPF policy. This has all been fixed with DKIM and DMARC, but setting '-all' may prevent this from working. > Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place. Because SPF is broken by design, and DKIM and DMARC have solved this. You are not going to get 'better' security with -all, since SPF does not provide any real security. To simplify: SPF is broken by design. DMARC is better, but '-all' is not compatible with DMARC. So, the article discusses that the actual proper configuration of SPF is ~all, since you do not want to rely on SPF anyway.

by LeonM 4y ago

johnklos 4y ago

I don't understand this. First you're talking about forwarding / relaying you don't control, which... you shouldn't care about. If someone else wants to forward / relay, then they need to worry about SPF breakage. You don't, nor should you. Then, you're talking about something entirely different: "That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation." Huh? No. If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong. Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all. Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.

LeonM 4y ago
For DMARC, you need SPF or DKIM to be aligned for the email to be accepted. One of the two is enough for the receiver to accept the email based on DMARC. This is how DMARC is designed, I can't change that. You can have an SPF fail but aligned DKIM, the email will be accepted. You can have SPF alignment without a DKIM signature, and still be accepted. If you have neither, the email will be rejected. This was all designed with backwards compatibility in mind. This was back in the days that not every email service was capable of signing with DKIM, so for those you could still use SPF. However, it was already widely accepted back then that SPF was very much broken by design, and you should use DKIM instead (but keep SPF for backwards compatibility). DKIM is much better in terms of security (it uses actual cryptography) and reliability (much less likely to break beyond your control). If your email services support DKIM, you should use that. > If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong. DKIM is able to disagree with SPF, that's how DMARC is designed. If you an email has a valid signature, but not valid SPF, your email should still be accepted. > Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all. It think you are missing something. You can set a '-all' policy, but then you risk making you own perfectly authentic and DKIM signed email undeliverable. You cannot rely on SPF to pass, even if you have the sender set up correctly in the SPF policy. This has all been fixed with DKIM and DMARC, but setting '-all' may prevent this from working. > Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place. Because SPF is broken by design, and DKIM and DMARC have solved this. You are not going to get 'better' security with -all, since SPF does not provide any real security. To simplify: SPF is broken by design. DMARC is better, but '-all' is not compatible with DMARC. So, the article discusses that the actual proper configuration of SPF is ~all, since you do not want to rely on SPF anyway.