Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
> On Apr 7, 2024, at 6:20 PM, Scott Kitterman wrote: > > > >> On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz >> wrote: >> >> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote: >>> >>> >>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: Scott Kitterman writes: > I hear you. Your operational issue is my system working as designed. > DMARC works on top of SPF, it doesn't change it. Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We are trying to change the fact that people rely purely on SPF, and try to get them moved to use DMARC istead, and we are trying to explain that if you do SPF inside the DMARC context, you get exactly same policy results you get as when you do SPF before, except you get it better, as you have more data available. Using -all would be completely ok if everybody would be doing DMARC, but as there are some systems which do SPF outside DMARC, and there having -all might shortcircuit DMARC out from the equation, we should provide guidance to those people how they can get best results in current environment. Thus the best current practice should be use to use ~all instead of -all if you are trying to use DMARC, and want other systems to actually act based on your DMARC policy. >> >> The problem I see is that some receivers never got the memo and still >> enforce just on an SPF hard fail which only creates fear, uncertainty, >> doubt, and annoyance. > > > If there's FUD, it's due to claiming it is a significant problem for DMARC. > Everyone has a different mail stream, so YMMV, but in my experience this is > approximately never an issue. This is only even potentially an issue when > Mail From aligned and SPF is fail. I don't recall the last time I saw that > happen for a message that also passed DKIM (and d= was aligned). > > What is the overwhelming case for me is Mail From is not aligned (like this > mailing list) and SPF is pass, none, neutral, etc. Even if the receiver > rejects SPF fail, it almost never comes up. Then the DMARC result is a > function of the DKIM signature verifying and being aligned. The fact that my > domain has a -all SPF record virtually never matters for DMARC. > > So let's move on... Let’s move on. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz wrote: > > >> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote: >> >> >> >>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: >>> >>> Scott Kitterman writes: I hear you. Your operational issue is my system working as designed. DMARC works on top of SPF, it doesn't change it. >>> >>> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We >>> are trying to change the fact that people rely purely on SPF, and try >>> to get them moved to use DMARC istead, and we are trying to explain >>> that if you do SPF inside the DMARC context, you get exactly same >>> policy results you get as when you do SPF before, except you get it >>> better, as you have more data available. Using -all would be >>> completely ok if everybody would be doing DMARC, but as there are some >>> systems which do SPF outside DMARC, and there having -all might >>> shortcircuit DMARC out from the equation, we should provide guidance >>> to those people how they can get best results in current environment. >>> Thus the best current practice should be use to use ~all instead of >>> -all if you are trying to use DMARC, and want other systems to >>> actually act based on your DMARC policy. > >The problem I see is that some receivers never got the memo and still enforce >just on an SPF hard fail which only creates fear, uncertainty, doubt, and >annoyance. If there's FUD, it's due to claiming it is a significant problem for DMARC. Everyone has a different mail stream, so YMMV, but in my experience this is approximately never an issue. This is only even potentially an issue when Mail From aligned and SPF is fail. I don't recall the last time I saw that happen for a message that also passed DKIM (and d= was aligned). What is the overwhelming case for me is Mail From is not aligned (like this mailing list) and SPF is pass, none, neutral, etc. Even if the receiver rejects SPF fail, it almost never comes up. Then the DMARC result is a function of the DKIM signature verifying and being aligned. The fact that my domain has a -all SPF record virtually never matters for DMARC. So let's move on... Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote: > > > >> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: >> >> Scott Kitterman writes: >>> I hear you. Your operational issue is my system working as designed. >>> DMARC works on top of SPF, it doesn't change it. >> >> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We >> are trying to change the fact that people rely purely on SPF, and try >> to get them moved to use DMARC istead, and we are trying to explain >> that if you do SPF inside the DMARC context, you get exactly same >> policy results you get as when you do SPF before, except you get it >> better, as you have more data available. Using -all would be >> completely ok if everybody would be doing DMARC, but as there are some >> systems which do SPF outside DMARC, and there having -all might >> shortcircuit DMARC out from the equation, we should provide guidance >> to those people how they can get best results in current environment. >> Thus the best current practice should be use to use ~all instead of >> -all if you are trying to use DMARC, and want other systems to >> actually act based on your DMARC policy. The problem I see is that some receivers never got the memo and still enforce just on an SPF hard fail which only creates fear, uncertainty, doubt, and annoyance. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
We can complain about people treating SPF Fail as definitive, but DMARC perpetuates the very same myth, which is: “If Sender Authentication test X produces FAIL, then the message is malicious and should be blocked.” It does not matter whether "X" is SPF Fail, DKIM Fail, ADSP Fail, DMARC Fail, or DMARC Fail with Reject. The proposition is at best a probability statement. Anyone who treats it as absolute will make significant disposition mistakes. In DMARC Land, we call that the "Mailing List Problem", even though the problem is not limited to mailing lists. In an attempt to save the myth, we keep narrowing scope, which guides people to ignore a lot of malicious activity. Then to make things worse, we guide people to respond incorrectly when malicious activity is actually detected. We need to abandon the myth. Doug Foster On Sat, Apr 6, 2024 at 4:40 PM John Levine wrote: > It appears that Scott Kitterman said: > >I hear you. Your operational issue is my system working as designed. > DMARC > >works on top of SPF, it doesn't change it. > > > >Anything like this belongs in an operational guidance document, not in > the > >protocol description. I have no problem describing the trade offs in an > >appropriate document, but I don't think this is it. > > I agree. "Don't do stupid stuff" goes in an A/S, not in the spec. > > I entirely believe people are confused about SPF, but they're confused > about everything. A few days ago on the generally clueful NANOG list > we had to explain to someone that rejecting mail if DKIM signatures > don't verify is not a good idea. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: This WG should have finished a year ago. Unless you think something is so broken that it's worth more months of delay, forget it. To be clear I was suggesting considering deprecating the hardfail modifier only as it’s archaic. I was not saying deprecate SPF. That said, i don’t know what the unexpected consequences of this change would be. I think SPF still has its place. Maybe they’ll make some adjustments over in the SPF working group. It's not a terrible idea, but this is dmarc-bis, not spf-bis. It's way outside the scope of this WG. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
> On Apr 7, 2024, at 9:27 AM, John R Levine wrote: > > On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: >> I think clear statement and supporting text explaining clearly that SPF is >> no longer the policy layer would be a good idea. While it might be slightly >> out of scope, I have encountered people who think best practice is to >> enforce with -ALL. > > We had a long discussion about that which you can read in the list archive at > https://mailarchive.ietf.org/arch/browse/dmarc/ > > Nobody is crazy about SPF but removing it completely is too much of a change. > As Ale pointed out, if you don't want people to use SPF for your DMARC > validation, make all your SPF entries ? or ~ rather than +. > > This WG should have finished a year ago. Unless you think something is so > broken that it's worth more months of delay, forget it. To be clear I was suggesting considering deprecating the hardfail modifier only as it’s archaic. I was not saying deprecate SPF. That said, i don’t know what the unexpected consequences of this change would be. I think SPF still has its place. Maybe they’ll make some adjustments over in the SPF working group. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: I think clear statement and supporting text explaining clearly that SPF is no longer the policy layer would be a good idea. While it might be slightly out of scope, I have encountered people who think best practice is to enforce with -ALL. We had a long discussion about that which you can read in the list archive at https://mailarchive.ietf.org/arch/browse/dmarc/ Nobody is crazy about SPF but removing it completely is too much of a change. As Ale pointed out, if you don't want people to use SPF for your DMARC validation, make all your SPF entries ? or ~ rather than +. This WG should have finished a year ago. Unless you think something is so broken that it's worth more months of delay, forget it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: > > Scott Kitterman writes: >> I hear you. Your operational issue is my system working as designed. >> DMARC works on top of SPF, it doesn't change it. > > Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We > are trying to change the fact that people rely purely on SPF, and try > to get them moved to use DMARC istead, and we are trying to explain > that if you do SPF inside the DMARC context, you get exactly same > policy results you get as when you do SPF before, except you get it > better, as you have more data available. Using -all would be > completely ok if everybody would be doing DMARC, but as there are some > systems which do SPF outside DMARC, and there having -all might > shortcircuit DMARC out from the equation, we should provide guidance > to those people how they can get best results in current environment. > Thus the best current practice should be use to use ~all instead of > -all if you are trying to use DMARC, and want other systems to > actually act based on your DMARC policy. > >> Anything like this belongs in an operational guidance document, not in the >> protocol description. I have no problem describing the trade offs in an >> appropriate document, but I don't think this is it. >> > I think you’re right the core document should be kept sacred but a DMARCbis pointing to an operational document that discusses the trade offs and perhaps goes so far as to recommend best practices if that seems appropriate. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
Scott Kitterman writes: > I hear you. Your operational issue is my system working as designed. > DMARC works on top of SPF, it doesn't change it. Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We are trying to change the fact that people rely purely on SPF, and try to get them moved to use DMARC istead, and we are trying to explain that if you do SPF inside the DMARC context, you get exactly same policy results you get as when you do SPF before, except you get it better, as you have more data available. Using -all would be completely ok if everybody would be doing DMARC, but as there are some systems which do SPF outside DMARC, and there having -all might shortcircuit DMARC out from the equation, we should provide guidance to those people how they can get best results in current environment. Thus the best current practice should be use to use ~all instead of -all if you are trying to use DMARC, and want other systems to actually act based on your DMARC policy. > Anything like this belongs in an operational guidance document, not in the > protocol description. I have no problem describing the trade offs in an > appropriate document, but I don't think this is it. > -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
That would probably be a question better placed on the SPFbis list, and (IETF veterans, keep me honest) it probably wouldn't be able to be addressed fully unless SPFter becomes a thing at some point. Outside of unnecessary/unexpected uses of it (due to reasons outlined previously in the thread), there's still valid, expected, and reasonable use cases of it as it stands today. Personally, I don't see a need for it to be deprecated. - Mark Alley On 4/7/2024 7:52 AM, Neil Anuskiewicz wrote: Forgive me if this a dumb idea but, Scott and others, any discussion of just deprecating SPF hardfail at some point? On Apr 6, 2024, at 1:40 PM, John Levine wrote: It appears that Scott Kitterman said: I hear you. Your operational issue is my system working as designed. DMARC works on top of SPF, it doesn't change it. Anything like this belongs in an operational guidance document, not in the protocol description. I have no problem describing the trade offs in an appropriate document, but I don't think this is it. I agree. "Don't do stupid stuff" goes in an A/S, not in the spec. I entirely believe people are confused about SPF, but they're confused about everything. A few days ago on the generally clueful NANOG list we had to explain to someone that rejecting mail if DKIM signatures don't verify is not a good idea. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
Forgive me if this a dumb idea but, Scott and others, any discussion of just deprecating SPF hardfail at some point? > On Apr 6, 2024, at 1:40 PM, John Levine wrote: > > It appears that Scott Kitterman said: >> I hear you. Your operational issue is my system working as designed. DMARC >> works on top of SPF, it doesn't change it. >> >> Anything like this belongs in an operational guidance document, not in the >> protocol description. I have no problem describing the trade offs in an >> appropriate document, but I don't think this is it. > > I agree. "Don't do stupid stuff" goes in an A/S, not in the spec. > > I entirely believe people are confused about SPF, but they're confused > about everything. A few days ago on the generally clueful NANOG list > we had to explain to someone that rejecting mail if DKIM signatures > don't verify is not a good idea. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
> On Apr 6, 2024, at 1:40 PM, John Levine wrote: > > It appears that Scott Kitterman said: >> I hear you. Your operational issue is my system working as designed. DMARC >> works on top of SPF, it doesn't change it. >> >> Anything like this belongs in an operational guidance document, not in the >> protocol description. I have no problem describing the trade offs in an >> appropriate document, but I don't think this is it. > > I agree. "Don't do stupid stuff" goes in an A/S, not in the spec. > > I entirely believe people are confused about SPF, but they're confused > about everything. A few days ago on the generally clueful NANOG list > we had to explain to someone that rejecting mail if DKIM signatures > don't verify is not a good idea. > > R's, > John > I think clear statement and supporting text explaining clearly that SPF is no longer the policy layer would be a good idea. While it might be slightly out of scope, I have encountered people who think best practice is to enforce with -ALL. It’s not that it’s stupid to do that, it’s just that email auth is still kind of obscure knowledge for some reason I don’t quite understand since it’s been a while. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
It appears that Scott Kitterman said: >I hear you. Your operational issue is my system working as designed. DMARC >works on top of SPF, it doesn't change it. > >Anything like this belongs in an operational guidance document, not in the >protocol description. I have no problem describing the trade offs in an >appropriate document, but I don't think this is it. I agree. "Don't do stupid stuff" goes in an A/S, not in the spec. I entirely believe people are confused about SPF, but they're confused about everything. A few days ago on the generally clueful NANOG list we had to explain to someone that rejecting mail if DKIM signatures don't verify is not a good idea. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
I hear you. Your operational issue is my system working as designed. DMARC works on top of SPF, it doesn't change it. Anything like this belongs in an operational guidance document, not in the protocol description. I have no problem describing the trade offs in an appropriate document, but I don't think this is it. Scott K On Saturday, April 6, 2024 1:47:07 PM EDT Seth Blank wrote: > You’re not hearing me— this is something that comes up frequently for > organizations working to implement DMARC. Others have confirmed on list. > This is not an academic concern, it’s an operational one as elevated by the > charter. > > Your other examples you cited do not come up in practice as issues for > domain owners looking to do DMARC. > > Yes, let’s get back to N. > > S > > Seth Blank | Chief Technology Officer > Email: s...@valimail.com > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > On Sat, Apr 6, 2024 at 13:44 Scott Kitterman wrote: > > The same thing can be said for every step of email processing that comes > > before DMARC. If I reject your mail due to your IP being on a block list, > > you > > also don't get DMARC feedback about it. > > > > It was long enough ago that I don't remember if it was RFC 7489 or early > > in > > this working group, but we did have extensive discussions about this > > before > > and that's how we got where we are. I don't think there's a lot of value > > in > > redoing that discussion. > > > > I think your N=5 versus N=8 topic is more important and much more on > > topic. > > > > Scott K > > > > On Saturday, April 6, 2024 1:27:18 PM EDT Seth Blank wrote: > > > Scott, I disagree. > > > > > > SPF hardfail in a DMARC context is an operational issue that comes up > > > > with > > > > > some frequency for domain owners. > > > > > > We should have some minimal amount of clarifying text. > > > > > > S, individually > > > > > > Seth Blank | Chief Technology Officer > > > Email: s...@valimail.com > > > > > > > > > This email and all data transmitted with it contains confidential and/or > > > proprietary information intended solely for the use of individual(s) > > > authorized to receive it. If you are not an intended and authorized > > > recipient you are hereby notified of any use, disclosure, copying or > > > distribution of the information included in this transmission is > > > > prohibited > > > > > and may be unlawful. Please immediately notify the sender by replying to > > > this email and then delete it from your system. > > > > > > On Sat, Apr 6, 2024 at 13:01 Scott Kitterman > > > > wrote: > > > > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > > > > > Greetings. > > > > > > > > > > Issue 141 has been opened to collect ideas around the discussion > > > > about > > > > > > what > > > > > > > > > to say in DMARCbis (if anything) about honoring SPF records that end > > > > in > > > > > > > -all when SPF fails. > > > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 > > > > > > I don't really understand the need for this. What to do when SPF > > > > produces > > > > > > a > > > > fail result is an SPF question. Not a DMARC question. Additionally, > > > > we > > > > > > have > > > > discussed this before. Note that not even RFC 7208 tells receivers > > > > what > > > > > > to do > > > > with SPF fail. It seems far, far out of scope to do so here. > > > > > > > > On the theory that the invocation not to relitigate things we've > > > > already > > > > > > gone > > > > through won't be honored entirely in the breach, can we not do this? > > > > > > > > Scott K > > > > > > > > > > > > > > > > ___ > > > > dmarc mailing list > > > > dmarc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
You’re not hearing me— this is something that comes up frequently for organizations working to implement DMARC. Others have confirmed on list. This is not an academic concern, it’s an operational one as elevated by the charter. Your other examples you cited do not come up in practice as issues for domain owners looking to do DMARC. Yes, let’s get back to N. S Seth Blank | Chief Technology Officer Email: s...@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. On Sat, Apr 6, 2024 at 13:44 Scott Kitterman wrote: > The same thing can be said for every step of email processing that comes > before DMARC. If I reject your mail due to your IP being on a block list, > you > also don't get DMARC feedback about it. > > It was long enough ago that I don't remember if it was RFC 7489 or early > in > this working group, but we did have extensive discussions about this > before > and that's how we got where we are. I don't think there's a lot of value > in > redoing that discussion. > > I think your N=5 versus N=8 topic is more important and much more on topic. > > Scott K > > On Saturday, April 6, 2024 1:27:18 PM EDT Seth Blank wrote: > > Scott, I disagree. > > > > SPF hardfail in a DMARC context is an operational issue that comes up > with > > some frequency for domain owners. > > > > We should have some minimal amount of clarifying text. > > > > S, individually > > > > Seth Blank | Chief Technology Officer > > Email: s...@valimail.com > > > > > > This email and all data transmitted with it contains confidential and/or > > proprietary information intended solely for the use of individual(s) > > authorized to receive it. If you are not an intended and authorized > > recipient you are hereby notified of any use, disclosure, copying or > > distribution of the information included in this transmission is > prohibited > > and may be unlawful. Please immediately notify the sender by replying to > > this email and then delete it from your system. > > > > On Sat, Apr 6, 2024 at 13:01 Scott Kitterman > wrote: > > > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > > > > Greetings. > > > > > > > > Issue 141 has been opened to collect ideas around the discussion > about > > > > > > what > > > > > > > to say in DMARCbis (if anything) about honoring SPF records that end > in > > > > -all when SPF fails. > > > > > > > > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 > > > > > > I don't really understand the need for this. What to do when SPF > produces > > > a > > > fail result is an SPF question. Not a DMARC question. Additionally, > we > > > have > > > discussed this before. Note that not even RFC 7208 tells receivers > what > > > to do > > > with SPF fail. It seems far, far out of scope to do so here. > > > > > > On the theory that the invocation not to relitigate things we've > already > > > gone > > > through won't be honored entirely in the breach, can we not do this? > > > > > > Scott K > > > > > > > > > > > > ___ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
The same thing can be said for every step of email processing that comes before DMARC. If I reject your mail due to your IP being on a block list, you also don't get DMARC feedback about it. It was long enough ago that I don't remember if it was RFC 7489 or early in this working group, but we did have extensive discussions about this before and that's how we got where we are. I don't think there's a lot of value in redoing that discussion. I think your N=5 versus N=8 topic is more important and much more on topic. Scott K On Saturday, April 6, 2024 1:27:18 PM EDT Seth Blank wrote: > Scott, I disagree. > > SPF hardfail in a DMARC context is an operational issue that comes up with > some frequency for domain owners. > > We should have some minimal amount of clarifying text. > > S, individually > > Seth Blank | Chief Technology Officer > Email: s...@valimail.com > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > On Sat, Apr 6, 2024 at 13:01 Scott Kitterman wrote: > > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > > > Greetings. > > > > > > Issue 141 has been opened to collect ideas around the discussion about > > > > what > > > > > to say in DMARCbis (if anything) about honoring SPF records that end in > > > -all when SPF fails. > > > > > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 > > > > I don't really understand the need for this. What to do when SPF produces > > a > > fail result is an SPF question. Not a DMARC question. Additionally, we > > have > > discussed this before. Note that not even RFC 7208 tells receivers what > > to do > > with SPF fail. It seems far, far out of scope to do so here. > > > > On the theory that the invocation not to relitigate things we've already > > gone > > through won't be honored entirely in the breach, can we not do this? > > > > Scott K > > > > > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
Scott, I disagree. SPF hardfail in a DMARC context is an operational issue that comes up with some frequency for domain owners. We should have some minimal amount of clarifying text. S, individually Seth Blank | Chief Technology Officer Email: s...@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. On Sat, Apr 6, 2024 at 13:01 Scott Kitterman wrote: > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > > Greetings. > > > > Issue 141 has been opened to collect ideas around the discussion about > what > > to say in DMARCbis (if anything) about honoring SPF records that end in > > -all when SPF fails. > > > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 > > I don't really understand the need for this. What to do when SPF produces > a > fail result is an SPF question. Not a DMARC question. Additionally, we > have > discussed this before. Note that not even RFC 7208 tells receivers what > to do > with SPF fail. It seems far, far out of scope to do so here. > > On the theory that the invocation not to relitigate things we've already > gone > through won't be honored entirely in the breach, can we not do this? > > Scott K > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > Greetings. > > Issue 141 has been opened to collect ideas around the discussion about what > to say in DMARCbis (if anything) about honoring SPF records that end in > -all when SPF fails. > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 I don't really understand the need for this. What to do when SPF produces a fail result is an SPF question. Not a DMARC question. Additionally, we have discussed this before. Note that not even RFC 7208 tells receivers what to do with SPF fail. It seems far, far out of scope to do so here. On the theory that the invocation not to relitigate things we've already gone through won't be honored entirely in the breach, can we not do this? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
Greetings. Issue 141 has been opened to collect ideas around the discussion about what to say in DMARCbis (if anything) about honoring SPF records that end in -all when SPF fails. https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
