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
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
> 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
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
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
> 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
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
> 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
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
It appears that Tobias Herkula said:
>However, such a fundamental shift in the protocol's architecture warrants a
>clear signifier. I suggest we upgrade
>our DMARC version string from the current state to 'DMARC2.' This upgrade
>would not only denote the change of SPF
>removal, but also the
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
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
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
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
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
If we move to DMARC2 version string this would be solved easily, we could add
the requirement to the tree-walk algo, we fallback to DMARC1 records if the
tree-walk does not find a DMARC2 one. So, the long-tail can continue running in
their current environment and upgrade on their own pace to
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
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
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
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
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
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
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%)
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,
24 matches
Mail list logo
