My #1 concern is how the bigger ESP is contributing to the delivery problems, causing chaos for business users and customer relationship problems with mail hosting provider I am seeing uncertainty and inconsistency among different receivers with ESP gmail.com seems to be the most aggressive and I am seeing the bigger ESPs using different methods, including proprietary methods.
As a sideline note, I will venture email overhead has skyrocketed to a new level of hard to follow headers for tech support. I don’t think we can continue down this path in the name of trying to get DMARC as apart of everyone’s domain when in fact, it is unfortunately becoming more apparent, a domain may be is better off with no DMARC record, not even p=none may help. Using SPF is good enough it seems. — HLS > On Jun 8, 2023, at 11:02 AM, Barry Leiba <barryle...@computer.org> wrote: > > I disagree with the premise (the last sentence of your first paragraph). > Broken or ineffective authentication is worse than none, because it causes > deliverability problems. I’d rather have no authentication and rely on other > means of filtering. > > Barry > > On Thu, Jun 8, 2023 at 3:54 PM Seth Blank <s...@sethblank.com > <mailto:s...@sethblank.com>> wrote: >> Participating, while running around so apologies for terseness: >> >> Sophisticated senders do DKIM. The long tail, we're lucky if they do SPF. >> Some authentication is better than none. >> >> The problem isn't people evaluating SPF vs DKIM and choosing the easier >> option. It's people who have a business, who bolt on email, and then >> struggle to authenticate through any means. Again, we're lucky when we get >> SPF from them, and I'll still take that over no auth all day every day. >> >> Don't disagree at all with the myriad problems with SPF, and that the goal >> should be to eliminate it. I just don't believe we're anywhere close to that >> being a reality yet. >> >> The data that led to DMARC showed that SPF and DKIM were both necessary to >> determine legitimacy broadly. What would we need to understand now to see if >> only DKIM is necessary? >> >> On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba <barryle...@computer.org >> <mailto:barryle...@computer.org>> wrote: >>> See, I don't look at it as "harmed". Rather, I think they're using "we use >>> SPF" as a *reason* not to use DKIM, and I think that *causes* harm. >>> >>> SPF is, as I see it, worse than useless, as it adds no value to domain that >>> use DKIM -- any time DKIM fails SPF will also fail -- and actually impedes >>> the adoption of DKIM. Reliance on SPF causes DMARC failures that result in >>> deliverability problems for legitimate mail. I wholeheartedly support >>> removal of SPF as an authentication mechanism that DMARC accepts. >>> >>> Barry, as participant >>> >>> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank >>> <seth=40valimail....@dmarc.ietf.org <mailto:40valimail....@dmarc.ietf.org>> >>> wrote: >>>> Participating, I have data that I believe points to a long tail of >>>> businesses who predominantly only authenticate on behalf of others using >>>> SPF, and would be harmed by such a change. It will take me a little while >>>> to confirm and share. >>>> >>>> I also know a predominant ccTLD with millions of registrations, that has >>>> SPF on roughly 80% of them, but DMARC on barely 5%. I don't have data on >>>> DKIM for those, but I assume it's closer to the DMARC penetration than the >>>> SPF one. I'll see if I can get this data to share more publically, and >>>> also get the DKIM answer. >>>> >>>> Of course the goal is aligned dkim with a stated policy, but I don't think >>>> the data supports us being anywhere close to that realistically. >>>> >>>> As Chair, this is a valuable conversation to have with real data on >>>> problems and opportunities at scale, and am excited to see Tobias share >>>> and see what others have to say. >>>> >>>> Seth >>>> >>>> On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy <superu...@gmail.com >>>> <mailto:superu...@gmail.com>> wrote: >>>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula >>>>> <tobias.herkula=401und1...@dmarc.ietf.org >>>>> <mailto:401und1...@dmarc.ietf.org>> wrote: >>>>>> My team recently concluded an extensive study on the current use and >>>>>> performance of DMARC. We analyzed a staggering 3.2 billion emails, and >>>>>> the insights drawn are quite enlightening. Of these, 2.2 billion emails >>>>>> (approximately 69%) passed the DMARC check successfully. It's quite an >>>>>> achievement, reflective of our collective hard work in fostering a >>>>>> safer, more secure email environment. >>>>>> >>>>>> >>>>>> However, upon further analysis, it's evident that a mere 1.6% (or >>>>>> thirty-six million) of these DMARC-passed emails relied exclusively on >>>>>> the Sender Policy Framework (SPF) for validation. This is a remarkably >>>>>> low volume compared to the overall DMARC-passed traffic, raising >>>>>> questions about SPF's relevancy and the load it imposes on the DNS >>>>>> systems. >>>>>> >>>>>> >>>>>> >>>>>> Given the current use case scenarios and the desire to optimize our >>>>>> resources, I propose that we explore the possibility of removing the SPF >>>>>> dependency from DMARC. This step could result in a significant reduction >>>>>> in DNS load, increased efficiency, and an accurate alignment with our >>>>>> predominant use cases. >>>>>> >>>>>> [...] >>>>>> >>>>> >>>>> Does anyone have consonant (or dissonant) data? >>>>> >>>>> -MSK, participating >>>>> ______________
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
