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] I-D Action: draft-ietf-dmarc-failure-reporting-10.txt
It appears that Neil Anuskiewicz said: >Do you all think we should mention the decline and fall of the failure report? >I think that Yahoo! is the only major MBP that still sends >failure reports. I think the others may have stopped over PII concerns. I still get a dozen a day. They're not popular for good reasons, but they're not dead. 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
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] I-D Action: draft-ietf-dmarc-failure-reporting-10.txt
> On Mar 17, 2024, at 9:12 AM, Alessandro Vesely wrote:
>
> On Sun 17/Mar/2024 16:50:40 +0100 internet-drafts wrote:
>> Internet-Draft draft-ietf-dmarc-failure-reporting-10.txt is now available. It
>> is a work item of the Domain-based Message Authentication, Reporting &
>> Conformance (DMARC) WG of the IETF.
>>Title: Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC) Failure Reporting
>>Authors: Steven M Jones
>> Alessandro Vesely
>>Name:draft-ietf-dmarc-failure-reporting-10.txt
>>Pages: 16
>>Dates: 2024-03-17
>
>
> However we close the fifth point of issue 133[*], I added a new paragraph to
> delimit failure reporting scope:
>
> 3. Other Failure Reports
>
>This document only describes DMARC failure reports. DKIM failure reports
>[RFC6651] and SPF failure reports [RFC6652] are described in their own
>documents. A Report Generator issuing a DMARC failure report may or may not
>simultaneously issue also a failure report specific to the failed
>authentication mechanism, according to its policy.
>
> It adds RFC665{1,2} as Informative References.
>
> Keep it? Change it, but how? Strike it?
>
>
> Best
> Ale
>
Do you all think we should mention the decline and fall of the failure report?
I think that Yahoo! is the only major MBP that still sends failure reports. I
think the others may have stopped over PII concerns.
N
___
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] the long march, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
On April 7, 2024 4:32:06 PM UTC, "John R. Levine" wrote: >On Sat, 6 Apr 2024, Scott Kitterman wrote: >> As a side effect of the switch to the tree walk approach in DMARCbis, this is >> no longer true. For any subdomain without a DMARC record, the domains above >> it in the tree are also checked, so you can specify a different policy/ >> reporting address for groups of subdomains below the org domain (as long as >> you don't get past the max N value in length). > >Huh, what? Whatever the tree walk finds is by definition the org domain. It's >the same whether you're using it to check alignment or send reports. > >> I can articulate that N=5 is based on the longest email relevant entry in the >> current PSL. Why N=8 and not N=7 or N=9? > >Seth says there are people who need N=8 but for business reasons he can't tell >us who they are. I'm not thrilled about that but I see little downside to >bumping the number up to 8. I expect that's where we end up, but I think we need something more than one of the chairs said there are secret reasons. 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 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] the long march, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
On Sat, 6 Apr 2024, Scott Kitterman wrote: As a side effect of the switch to the tree walk approach in DMARCbis, this is no longer true. For any subdomain without a DMARC record, the domains above it in the tree are also checked, so you can specify a different policy/ reporting address for groups of subdomains below the org domain (as long as you don't get past the max N value in length). Huh, what? Whatever the tree walk finds is by definition the org domain. It's the same whether you're using it to check alignment or send reports. I can articulate that N=5 is based on the longest email relevant entry in the current PSL. Why N=8 and not N=7 or N=9? Seth says there are people who need N=8 but for business reasons he can't tell us who they are. I'm not thrilled about that but I see little downside to bumping the number up to 8. Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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 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
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 7 06:00:04 2024
Count| Bytes | Who ++--- 103 ( 100%) | 943897 ( 100%) | Total 17 (16.5%) | 99355 (10.5%) | Alessandro Vesely 16 (15.5%) | 151624 (16.1%) | Murray S. Kucherawy 10 ( 9.7%) | 134619 (14.3%) | Seth Blank 10 ( 9.7%) | 67352 ( 7.1%) | Scott Kitterman 7 ( 6.8%) | 62365 ( 6.6%) | Todd Herr 7 ( 6.8%) | 35765 ( 3.8%) | John Levine 5 ( 4.9%) | 75347 ( 8.0%) | Douglas Foster 5 ( 4.9%) | 39532 ( 4.2%) | Jim Fenton 5 ( 4.9%) | 27791 ( 2.9%) | John R. Levine 3 ( 2.9%) | 38637 ( 4.1%) | Tim Wicinski 3 ( 2.9%) | 31423 ( 3.3%) | Dotzero 3 ( 2.9%) | 31015 ( 3.3%) | Emanuel Schorsch 3 ( 2.9%) | 24924 ( 2.6%) | Tero Kivinen 2 ( 1.9%) | 59026 ( 6.3%) | Brotman, Alex 1 ( 1.0%) | 17704 ( 1.9%) | OLIVIER HUREAU 1 ( 1.0%) | 14812 ( 1.6%) | Hector Santos 1 ( 1.0%) | 8675 ( 0.9%) | Mark Alley 1 ( 1.0%) | 7842 ( 0.8%) | Laura Atkins 1 ( 1.0%) | 6150 ( 0.7%) | Matthäus Wander 1 ( 1.0%) | 6053 ( 0.6%) | Richard Clayton 1 ( 1.0%) | 3886 ( 0.4%) | Baptiste Carvello ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
