Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 8, 2023, at 4:25 PM, Scott Kitterman wrote: > > The data I have seen (and it sounds like Mike is saying the same thing) > shows DKIM verification results are less than 100%, consistently, for direct > connections. It was always lower than the SPF pass rate for hosts listed in > a

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On June 20, 2023 4:33:48 PM UTC, John Levine wrote: >It appears that Tobias Herkula said: >>-=-=-=-=-=- >>Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >>maintain deliverability to those, you have to keep SPF >>records in place and can’t switch to an DKIM only

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

It appears that Tobias Herkula said: >-=-=-=-=-=- >Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >maintain deliverability to those, you have to keep SPF >records in place and can’t switch to an DKIM only DMARC. Nobody's saying you can't publish SPF. We're just

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

t; > > / Tobias > > > > *From:* dmarc *On Behalf Of * Murray S. Kucherawy > *Sent:* Sunday, June 18, 2023 2:42 AM > *To:* Ken Simpson > *Cc:* Douglas Foster ; Jan Dušátko > ; dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal > >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Simpson Cc: Douglas Foster ; Jan Dušátko ; dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson mailto:ksimp...@mailchannels.com>> wrote: FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from the next

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Mon 19/Jun/2023 20:42:28 +0200 Patrick Ben Koetter wrote: The number of IP addresses in SPF-Records published by VLMPs foils the idea of "a controlled and limited number of host allowed to send on behalf of a senderdomain". Given the (internal routing) challenges you face when you try to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Dear all, On the other hand for a hosting company, implementing SPF is just a matter of knowing where the emails are supposed to be sent from. You don't have anything to install on the outgoing mail servers to DKIM-sign. And with the "include" mechanism, it is very easy to maintain an

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

As DMARC is intended to protect the From header from spoofing, we support moving DMARCbis authentication to DKIM-only due to the recent demonstration of such spoofing that was enabled by an SPF upgrade attack as described in [1]. That paper cites the vulnerability of Federal government,

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

* Alessandro Vesely : > On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote: > > > > I rerun the statistics and yes, there is 0.84% cases where dkim > > failed, but spf returned either pass, softfail or neutral. > > Many thanks. That figure seems to be more or less in agreement with what >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Sun 18/Jun/2023 23:06:59 +0200 Ken Simpson wrote: The hosting provider has to hook up everything for them and presumably, with enough encouragement, we could eventually get hosting companies to implement DKIM signing for their customers. That is not the case today. Domain-based

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> DMARC requires using SPF or DKIM or SPF and DKIM. If neither method is > used, DMARC can report the situation, but it won't prevent receipt (m'I > correct?). You are not correct; DMARC is designed to handle this situation, among others. I'll oversimplify here, because you really do need to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Sun, Jun 18, 2023 at 10:56 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I suspect that many domain owners have not considered the possibility of > using DKIM with SPF NONE. > > Then there is the concern about evaluators that understand SPF but do not > understand DMARC.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Douglas, In my opinion, quite a number of administrators are aware of this possibility. But if someone were to send an e-mail for an organization (I mean a counterfeit e-mail), the recipient doesn't have a chance to verify whether the sender is actually using DKIM or not. The attacker can

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

I suspect that many domain owners have not considered the possibility of using DKIM with SPF NONE. Then there is the concern about evaluators that understand SPF but do not understand DMARC. Do they treat SPF NONE as acceptable or suspicious? For your situation Ken, do your clients have the

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 17, 2023, at 9:50 PM, John Levine wrote: > > It appears that Hector Santos said: >>> Can these senders not accomplish the same thing by removing the SPF record >>> altogether? >>> >>> -MSK, participating >> >> >> Isn’t SPF, DKIM and alignment are all required for DMARC1 passage?

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

It appears that Hector Santos said: >> Can these senders not accomplish the same thing by removing the SPF record >> altogether? >> >> -MSK, participating > > >Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure if >any are missing? No, that has never been the case.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 17, 2023, at 8:41 PM, Murray S. Kucherawy wrote: > > On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson > wrote: >> FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from >> the next iteration of DMARC. As the operator of an email

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson wrote: > FWIW, I'd like to chuck my hat in the ring on the side of removing SPF > from the next iteration of DMARC. As the operator of an email delivery > service with tens of millions of primarily uncontrolled senders on web > hosting servers, it

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from the next iteration of DMARC. As the operator of an email delivery service with tens of millions of primarily uncontrolled senders on web hosting servers, it would be *great* if domain owners could assert via their DMARC

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

In general, message recipients lack the expertise needed to distinguish between legitimate and fraudulent identities.Most users do not know how to read message headers or how to make sense of them if shown. Whenour automated evaluation systems and administrative quarantine cannot resolve an

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Hi I would like to know your opinion on the options currently available to the system administrator. If it is trying to define a policy that allows recipients to authenticate emails, its options are, in my opinion, limited. - The issue of SPF and cloud systems mentioned, or including over

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Hi, Am 16.06.2023 um 13:28 schrieb Sebastiaan de Vos: The need for separate DKIM failure codes to be able to separate between in-transit changes and public key errors is more than just valid and I don't consider SPF worthless in general, but I just find it disturbing how the obviously

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

The need for separate DKIM failure codes to be able to separate between in-transit changes and public key errors is more than just valid and I don't consider SPF worthless in general, but I just find it disturbing how the obviously misplaced confidence in SPF currently weakens the whole DMARC

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri 16/Jun/2023 13:02:46 +0200 Douglas Foster wrote: The solution is to talk about the differences in confidence provided by the different authentication methods, and note that evaluators have reason to distrust some of them. That distrust could cause a weakly authenticated message to be

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

RFC 7489 takes 8 different authentication mechanisms and lumps them into a single PASS result: DKIM or SPF, each with up to four types of alignment: same domain, parent->child, child->parent, and sibling->sibling These eight mechanisms all provide some level of confidence that the message is not

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Many thanks.  That figure seems to be more or less in agreement with what others here have obtained on smaller samples.  However small, it may confer to SPF the role of a stabilizer in DMARC mail flows. How could SPF be a stabilizer when it's proven to be a highly unreliable mechanism? I'd

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote: I rerun the statistics and yes, there is 0.84% cases where dkim failed, but spf returned either pass, softfail or neutral. Many thanks. That figure seems to be more or less in agreement with what others here have obtained on smaller

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 15, 2023 at 6:34 AM Tero Kivinen wrote: > Murray S. Kucherawy writes: > > On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote: > > > > DKIM failures > > > > > 36.34% 26619 invalid DKIM record

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Tuesday, June 13, 2023 5:33:50 PM EDT Tero Kivinen wrote: > Barry Leiba writes: > > > DKIM only: ~99.5% > > > DKIM + SPF: ~100% > > > SPF only: ~100% > > > > That's interesting and disturbing if it remains consistent. > > The statistics I have are quite different. The failure rate is much >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Tero Kivinen writes: > > What are those 0.75%, some 30k SPF - DKIM messages? Are there > > cases of DKIM random failure salvaged by SPF? > > My current analysis script does not try to calculate that, I would > need to need to add that step there and rerun the script. If I > understand correctly

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Alessandro Vesely writes: > On Tue 13/Jun/2023 23:33:50 +0200 Tero Kivinen wrote: > > [...] > > > > As you can see 85.75% of incoming email was already signed by DKIM, > > and 86.5% of emails had SPF records that passed. So they both have > > about same amount if usage coming in to our servers. >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Murray S. Kucherawy writes: > On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote: > >         DKIM failures >         >         36.34%  26619   invalid DKIM record > > This is staggering.  Can you characterize what

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >* The 5% with inconsistent results need further investigation.    > Perhaps a server farm has one server that is generating wrong > signatures. more likely the email has been "fixed up" by a

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Tue 13/Jun/2023 23:33:50 +0200 Tero Kivinen wrote: [...] As you can see 85.75% of incoming email was already signed by DKIM, and 86.5% of emails had SPF records that passed. So they both have about same amount if usage coming in to our servers. What are those 0.75%, some 30k SPF - DKIM

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

At M3AAWG a couple of years ago, a VLMB said that 60% of the DKIM errors they saw were obvious human error in the publishing of keys. This is why I’ve been pushing (through M3AAWG, and hopefully eventually via the appropriate working groups here) the need to automate publishing of DKIM keys.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote: > DKIM failures > > 36.34% 26619 invalid DKIM record > This is staggering. Can you characterize what the most common malformations are? -MSK

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

This topic raised a question, at least in my mind, whether DKIM signing algorithms are subject to random failures. If random failures occur, they could be blamed on either the sender algorithm or the receiver algorithm. The question can be assessed on incoming messages, using authentication

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Thanks for all this detail, Tero! I will have to digest it and reply further later. Barry On Tue, Jun 13, 2023 at 5:34 PM Tero Kivinen wrote: > > Barry Leiba writes: > > > DKIM only: ~99.5% > > > DKIM + SPF: ~100% > > > SPF only: ~100% > > > > That's interesting and disturbing if it remains

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Barry Leiba writes: > > DKIM only: ~99.5% > > DKIM + SPF: ~100% > > SPF only: ~100% > > That's interesting and disturbing if it remains consistent. The statistics I have are quite different. The failure rate is much bigger both in DKIM and SPF. Following statistics is random subset of emails

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

The misconfiguration is changing it after the message was signed. Once the message is signed and in the MTA-to-MTA relay system, no one should be altering the message body any more until final delivery. Barry On Mon, Jun 12, 2023 at 6:02 PM Jim Fenton wrote: > > On 9 Jun 2023, at 22:35, Murray

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 12, 2023, at 6:02 PM, Jim Fenton wrote: > > On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > >> >> You were previously talking about inserting ">" before a line starting >> "From ", which is typically done on delivery when writing to an >> mbox-formatted mailbox file, because

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > > You were previously talking about inserting ">" before a line starting > "From ", which is typically done on delivery when writing to an > mbox-formatted mailbox file, because in that format, "From " at the front > of a line has a specific

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <7f854d28-d3b5-fd00-4613-b8baa1217...@tana.it>, Alessandro Vesely writes >What I find nonsensical is to eliminate SPF in order to save DNS queries, at $DAYJOB$ (a large mailbox provider) SPF queries are limited to 15 ... since the

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Sat, Jun 10, 2023, at 12:50 AM, Barry Leiba wrote: > Are there working group participants who can do this sort of > evaluation, not just giving numbers but also analyzing why DKIM > failures happened when they should not have? As primarily an outbound ESP, we don't have access to relevant

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri 09/Jun/2023 17:33:16 +0200 Scott Kitterman wrote: You may not think that last half of a percent is important (my recollection is that it varied a bit between 0.2% and 0.8%), but I think it exists and is important. I only keep one month worth of DKIM and SPF results, and got 0.52% on it

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri, Jun 9, 2023 at 8:49 AM Alessandro Vesely wrote: > On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote: > > And signing software shouldn't be mutating messages ever (other than > adding > > signatures, of course). > > Section 5.3, Normalize the Message to Prevent Transport

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

1. It is out of the scope of our charter to make any changes to SPF, and that would include making it obsolete or Historic. 2. It is within the scope of our charter to make changes to DMARC, and that would include removing SPF evaluation from it. During the process of making changes to DMARC we

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Barry, Whoa! Take it easy. We are on the DMARC2 thread per topic - a proposal. Not anything for the current DMARCbis. Is the chair suggesting the current charter for DMARCbis should change to remove SPF? Was the charter changed for this? To be clear, DMARC2 is not DMARCbis right now, are

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Hector, did you not understand this?: >> We will *not* consider what should happen to >> SPF outside of DMARC, and any discussion of that is *out of scope* for >> this working group under its current charter. Please stop discussing it. Barry On Fri, Jun 9, 2023 at 8:23 PM Hector Santos wrote:

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 9, 2023, at 4:41 AM, Barry Leiba > wrote: > > Repeating this one point as chair, to make it absolutely clear: > > The proposal we're discussing is removing SPF authentication from > DMARC evaluation *only*. We will *not* consider what should happen to >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Thanks for the follow-up, Scott. > It's not a case of I've seen a few failures, it's consistent (all I can say > for certain is that it was as I no longer have access to this data). It was > consistent across time and providers. At scale, DKIM would always have a > fraction of a percent failure

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote: And signing software shouldn't be mutating messages ever (other than adding signatures, of course). Section 5.3, Normalize the Message to Prevent Transport Conversions, gives different advice. UTF-8, though, seems to be subject to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri 09/Jun/2023 11:14:29 +0200 Barry Leiba wrote: One case I saw multiple times where DKIM fails while SPF verifies is when the message contains a line starting with "from " which some agent changes to ">from ". Some signing software eliminates such lines before signing, but that's not in

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote: > I think, Scott, that you and I have a fundamental disagreement that's > not resolvable, and I won't just repeat what I've already said. But a > couple of the things you said are ones I can't make sense of, so I'll > > talk about those:

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Fri, Jun 9, 2023 at 2:14 AM Barry Leiba wrote: > > One case I saw multiple times where DKIM fails while SPF verifies is > when the > > message contains a line starting with "from " which some agent changes to > > ">from ". Some signing software eliminates such lines before signing, > but > >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> One case I saw multiple times where DKIM fails while SPF verifies is when the > message contains a line starting with "from " which some agent changes to > ">from ". Some signing software eliminates such lines before signing, but > that's not in the spec, so one cannot say a signer is defective

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu 08/Jun/2023 16:44:14 +0200 Barry Leiba 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. Does that mean SPF is easier to enter than DKIM? Maybe. It can be an advantage, though.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Repeating this one point as chair, to make it absolutely clear: The proposal we're discussing is removing SPF authentication from DMARC evaluation *only*. We will *not* consider what should happen to SPF outside of DMARC, and any discussion of that is *out of scope* for this working group under

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

I think, Scott, that you and I have a fundamental disagreement that's not resolvable, and I won't just repeat what I've already said. But a couple of the things you said are ones I can't make sense of, so I'll talk about those: > Software engineering isn't a perfect science. In general, a more

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

My Data: Data set: 360,000 messages. Scope notes: 1) Data is based on messages that passed successfully through sender filtering. I don't' care whether a sender authenticates when I know that I don't want his messages at all. 2) A DMARC-inspired authenticate test is applied to all messages, so

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

The data I have seen (and it sounds like Mike is saying the same thing) shows DKIM verification results are less than 100%, consistently, for direct connections. It was always lower than the SPF pass rate for hosts listed in a domain's SPF record. I understand that in theory, it shouldn't

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> There are DKIM verification failures for reasons unrelated to DNS failures. > As an example, I > recently fixed a DKIM validation bug in the library I maintain which was > causing a small fraction > of valid signatures to fail verification since at least 2011. SPF + DKIM > reduces DMARC

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On June 8, 2023 8:35:24 PM UTC, Barry Leiba wrote: >> A sender using both SPF and DMARC will see a slight >> boost in validation rates due to increased resiliency when there are >> transient DNS failures and other problems. > >Do you mean "both SPF and DKIM", perhaps? > >I don't see how that

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 8, 2023 at 4:35 PM Barry Leiba wrote: > > A sender using both SPF and DMARC will see a slight > > boost in validation rates due to increased resiliency when there are > > transient DNS failures and other problems. > > Do you mean "both SPF and DKIM", perhaps? > My bad. I responded

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> A sender using both SPF and DMARC will see a slight > boost in validation rates due to increased resiliency when there are > transient DNS failures and other problems. Do you mean "both SPF and DKIM", perhaps? I don't see how that makes sense: if there's a transient DNS failure, then neither

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 8, 2023 at 10:44 AM Barry Leiba 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. > That might be true but does not address whether or not SPF is/can be useful in the context of

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

> On Jun 8, 2023, at 10:20 AM, Murray S. Kucherawy wrote: > > On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula > 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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Scott Kitterman skrev den 2023-06-08 17:50: Isn't the way to say I don't use SPF for DMARC to not publish an SPF record? maybe "v=spf1 +all" or just something like over x numbers of ips, will trigger in dmarc not using spf ? ___ dmarc mailing

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

That would be how a sender says it, yes. The proposal we’re discussing is not to leave it up to the sender, but to tell the validator, as part of the DMARC protocol, not to evaluate SPF for the purpose of DMARC. BARRY On Thu, Jun 8, 2023 at 4:51 PM Scott Kitterman wrote: > Isn't the way to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

It’s not that simple for larger organizations, because of how distributed control of subdomains can be. You’d want to set an organizational policy to disallow SPF on the org domain. The problem with SPF is shared services. This has become so bad recently as to render many of the valuable bits of

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Isn't the way to say I don't use SPF for DMARC to not publish an SPF record? Scott K On June 8, 2023 3:35:38 PM UTC, Seth Blank wrote: >I’ll bring data. I think there’s a practical problem here and a class of >services that are not email-first which will break completely (ie get >immediately

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On June 8, 2023 2:20:44 PM UTC, "Murray S. Kucherawy" wrote: >On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

to the next DKIM only DMARC. / Tobias Von: Seth Blank Datum: Donnerstag, 8. Juni 2023 um 16:35 An: Barry Leiba Cc: Seth Blank , Tobias Herkula , "dmarc@ietf.org" Betreff: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal I’ll bring data. I think there’s a practical problem he

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

I’ll bring data. I think there’s a practical problem here and a class of services that are not email-first which will break completely (ie get immediately rejected) were such a change to be made. This feels like a significant interoperability problem we’d be introducing. I’m loathe to add flags

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Oh, and as to your last paragraph, I think it’s the wrong question. What we need to understand is that SPF is ineffective, and DKIM is what’s necessary to make DMARC work effectively. When we started, DKIM was not as broadly deployed and we didn’t understand how bad SPF would be. We have

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 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%)

[dmarc-ietf] DMARC2 & SPF Dependency Removal

Hi All, This message comes out of some discussions I had at the current MAAWG meeting in Dublin. I hope this message finds you well. The intent of this is to propose and discuss an evolutionary step in the DMARC protocol, which I believe will result in increased efficiency, reduced DNS load,