4 ms·

This is just flatly wrong: "One of them is that a relaying SMTP service (sometimes called a 'forwarder') will break SPF. This is known as the relaying problem.

This is just flatly wrong: "One of them is that a relaying SMTP service (sometimes called a 'forwarder') will break SPF. This is known as the relaying problem." 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. "If the email is bounced on the SMTP level due to an SPF 'hard' fail, the receiver may not perform further evaluation of the email, ignoring DKIM and DMARC." Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF. These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly.

0x073 4y ago
If i receive an mail from e.g. paypal@paypal.com to myself@xyz.com that has no real mailbox but forwards the mail to myself2815@gmail.com. 1. paypal SMTP sends mail to myself@xyz.com 2. xyz.com receive mail SPF is valid 3. xyz.com sends the paypal mail to myself2815@gmail.com 4. gmail.com receives mail SPF is invalid I can't add XYZ.com to Paypal SPF and hardfail would mean email loss in this case. SPF is broken by design for many cases and should just used with softfail and dkim/dmarc. There is arc but it has its own problems.
- throwaway67743 4y ago
  No, forwarding is broken by design, it always was. Configure whatever forwarding you use to do it properly, it's certainly doable (or just don't use gmail but a provider capable of handling this very common, if wrong, scenario)
  - pjkundert 4y ago
    SMTP "forwarding" (sending an email message with a header "To: <originaladdress>", to a different "RCPT TO: <differentaddress>") is "broken by design"? Sure, it's probably silly. But, SMTP is what it is, and you're not going to change it by complaining SPF's design just ... forgot about this, which happens all the time for email. Every MTA -- literally every forwarding MTA -- does this all day long, and every receiving MTA (which looks at the "Return-Path: <originaladdress>" to lookup the SPF TXT record), gets your fancy "v=spf1 ... nothing w/ forwarding MTA in it ... -all" record, and summarily executes the email w/ SPF: FAIL? It's just wrong. SPF can only serve as one (strong) hint that an email might be correct, if it passes. If it fails, all your MTA can assume is: "well, the email was very likely forwarded"; what else does it have going for it? If its "DKIM-Signature: ..." header is valid, that it's almost certainly A-OK! So, why do you want all your domain's nicely DKIM-signed emails dropped, just because some recipient decided to use a "forwarding" email address? That seems silly.
    - throwaway67743 4y ago
      SMTP forwarding is not the same as "forwarding" - it is very clear from the parent comment which one they mean, your response is re the wrong one.
      - pjkundert 4y ago
        Not sure I follow. I've been running public "forwarding" email servers for 20 years, and ... this is exactly what they do. This is exactly what Cloudflare's "forwarding" email solution does (except it has ARC and everyone who wants to support forwarding includes Cloudflare's MTAs in their ARC configuration). Little guys like me (of course) don't get included in anyone's ARC configuration, to patch over SPF's profound design failure. If you're describing a "forwarding" solution that doesn't simply do SMTP "RCPT TO" forwarding, then I don't understand what you're describing...
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.

0x073 4y ago

If i receive an mail from e.g. paypal@paypal.com to myself@xyz.com that has no real mailbox but forwards the mail to myself2815@gmail.com. 1. paypal SMTP sends mail to myself@xyz.com 2. xyz.com receive mail SPF is valid 3. xyz.com sends the paypal mail to myself2815@gmail.com 4. gmail.com receives mail SPF is invalid I can't add XYZ.com to Paypal SPF and hardfail would mean email loss in this case. SPF is broken by design for many cases and should just used with softfail and dkim/dmarc. There is arc but it has its own problems.

throwaway67743 4y ago
No, forwarding is broken by design, it always was. Configure whatever forwarding you use to do it properly, it's certainly doable (or just don't use gmail but a provider capable of handling this very common, if wrong, scenario)
- pjkundert 4y ago
  SMTP "forwarding" (sending an email message with a header "To: <originaladdress>", to a different "RCPT TO: <differentaddress>") is "broken by design"? Sure, it's probably silly. But, SMTP is what it is, and you're not going to change it by complaining SPF's design just ... forgot about this, which happens all the time for email. Every MTA -- literally every forwarding MTA -- does this all day long, and every receiving MTA (which looks at the "Return-Path: <originaladdress>" to lookup the SPF TXT record), gets your fancy "v=spf1 ... nothing w/ forwarding MTA in it ... -all" record, and summarily executes the email w/ SPF: FAIL? It's just wrong. SPF can only serve as one (strong) hint that an email might be correct, if it passes. If it fails, all your MTA can assume is: "well, the email was very likely forwarded"; what else does it have going for it? If its "DKIM-Signature: ..." header is valid, that it's almost certainly A-OK! So, why do you want all your domain's nicely DKIM-signed emails dropped, just because some recipient decided to use a "forwarding" email address? That seems silly.
  - throwaway67743 4y ago
    SMTP forwarding is not the same as "forwarding" - it is very clear from the parent comment which one they mean, your response is re the wrong one.
    - pjkundert 4y ago
      Not sure I follow. I've been running public "forwarding" email servers for 20 years, and ... this is exactly what they do. This is exactly what Cloudflare's "forwarding" email solution does (except it has ARC and everyone who wants to support forwarding includes Cloudflare's MTAs in their ARC configuration). Little guys like me (of course) don't get included in anyone's ARC configuration, to patch over SPF's profound design failure. If you're describing a "forwarding" solution that doesn't simply do SMTP "RCPT TO" forwarding, then I don't understand what you're describing...

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.