Re: [dmarc-ietf] DMARC and Data Hygiene

[Wei Chuang]

On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.


> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/


I would argue we can see a difference in the SPF and DKIM attacks with
respect to spoofing and that makes a difference for phishing.  With the SPF
upgrade attack, the adversary can spoof an arbitrary identity in the victim
domain and have it SPF authenticated.  See [1] for examples.  With DKIM
replay, the adversary needs access to an account in the victim domain to
obtain a signed message, but can't arbitrarily spoof some other identity in
the victim domain.

At a fundamental authentication property level, there are additional
differences too.  IPs tend to be shared more than private keys. Proving an
IP based validation to a third party is harder than with a digital
signature.  (This is one the issues of trusting the SPF results in
ARC-Authentication-Result, whereas with DKIM once can try to validate the
signature yourself).  On the other hand it's only fair to make
the observation that SPF is easier to set up than DKIM and we want to
capture those benefits as well.

We're definitely not saying SPF should be deprecated, and in fact we want
more deployment of SPF as it's highly complementary to DKIM both from a
deployment perspective but as a spam fighting signal.  We just want to
prevent its use in From header spoofing.

[1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf


>
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>

Just pointing out we're prototyping one of the drafts and there's
other work behind the scene.


> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are bot

Re: [dmarc-ietf] DMARC and Data Hygiene

[Dotzero]

On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.
>

> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>
> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are both real problems, but only because people are
> trying
> to make DMARC pass a positive assertion.  In order to do that reliably,
> organizations need to be more like Case 1 and be very careful vetting
> third
> parties that they authorize for.  I don't think that's a protocol problem.
>

I think this is a key factor for the calculus of value in DMARC " ...but
only because people are trying to make DMARC pass a positive assertion." I
agree that it's not a protocol implementation.

It really can't/shouldn't be used to try and make positive assertions (even
though people attempt to do so). Apart from the cases Scott points out,
there is the very real situation of when good domains go bad, whether
because the good domain has been subverted, sold or for other reasons. If
we move away from attempting to use DMARC to make a positive assertion then
the issues around configurations/implementations become less problematic.
Perfection is the enemy of good.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

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 DMARC.
>
>Nobody's saying you can't publish SPF.  We're just saying DMARC should ignore 
>it.

See the message I sent in a new thread for details.

I don't think this makes any sense.  There are problematic messages passing 
SPF.  Similarly there are problematic messages passing DKIM.  All dumping SPF 
does is increase the incentive to replay DKIM.

The problem here is domains authorizing their mail to be sent from under 
controlled third party sources.  Once SPF is gone, they'll use DKIM and still 
send "bad" messages.  Problem not solved.

If, for example, you deploy BIMI, and messages you didn't send get the BIMI 
marker, the solution is to hunt through your DMARC feedback reports, figure out 
which third party authenticated the message, and fire them.

This is an economics/incentives problem, not a technical problem.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

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 saying DMARC should ignore 
it.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DMARC and Data Hygiene

[Scott Kitterman]

I am starting a separate thread, because this isn't just about SPF.

I think the criticism of the reliability of SPF data is valid, but I think 
DKIM is similarly problematic.  Once you get rid of SPF, you'll find you 
haven't really solved much.  The next logical step will be to get rid of DKIM.

DKIM has man wonderful features, but the bottom line for DMARC is a valid DKIM 
signature indicates that the mail was sent (at some point) from an MTA that 
was authorized by the signing domain.  This is what a SPF pass result means 
too.  DKIM has broader utility in DMARC because it can persist through some 
indirect mail flows, but either way, an SPF pass and a valid DKIM signature 
both mean the message was authorized by the domain in the relevant identity.

The particular SPF problem that's being the focus of some much attention is 
addressed in the RFC 7208 security considerations (See section 11.4).

DKIM has a similar, but different problem.  The DKIM replay problem is bad 
enough that the IETF has chartered a working group to try to address it:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

I'll lay out examples to demonstrate:

Case 1 - First Party Only

An organization only authorizes email to be sent from MTAs it directly 
controls (I know this mostly doesn't exist, but it's useful to show where the 
problems are).  The organization does not send email for any third parties.

In this case, as long as the organization can limit sending to authorized 
users, the quality of both SPF and DKIM pass results should be well aligned 
with the nature of the mail the organization sends.

Case 2 - Sender For Others, Own Domain

An domain uses it's own domain to send mail for others (like all webmail 
providers).  The domain's email is sent using it's own infrastructure, so it 
doesn't need to worry directly about third parties.

In this case, there's still no real risk of external forgery, so an SPF or 
DKIM pass means it was sent by the domain.  The risk is to the domain's 
reputation if users sign up and use the service to send "bad" mail.

If the domain fails to prevent 'bad' messages from being sent, then these 'bad 
messages get a DMARC pass.  The mail is sent through the authorized email 
server, so it gets SPF pass and a valid DKIM signature.

This is a particular threat for DKIM, because once this succeeds for a single 
message, the user can replay the message on third party infrastructure to send 
it to large numbers of recipients.  This is the core issue the DKIM working 
group was resurrected to address.  It is not, however, clear that there's a 
protocol solution to this problem and the group has been pretty quiet 
recently.

Case 3 - Sender For Others, Their Domain

When organizations authorized third parties to send on their behalf (by 
publishing an SPF record or a DKIM public key record in DNS), they are 
trusting their domain's reputation to those third parties.

In particular, they are at risk of those third parties doing poor inbound 
validation and other customers of the authorized third parties injecting 'bad' 
mail authorized by their domain.

This is where I think the focus of recent discussion has been.

In these cases, email is emitted via third parties and passes SPF (may also be 
DKIM signed, but I suspect it's less common because replay is easier), so it's 
authorized, but unwanted.

Case 2 and Case 3 are both real problems, but only because people are trying 
to make DMARC pass a positive assertion.  In order to do that reliably, 
organizations need to be more like Case 1 and be very careful vetting third 
parties that they authorize for.  I don't think that's a protocol problem.

Scott K




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Todd Herr]

On Mon, Jun 19, 2023 at 8:25 PM John R Levine  wrote:

> On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
> > I suggest that we do not only drop SPF, but also come up with better ways
> > (simplification, tools, exchange formats) to implement DKIM in order to
> allow
> > for a smooth transition.
>
> I'm scratching my head here.  On my system I publish and rotate DKIM keys
> completely automatically.  The only manual config is to edit the list of
> domains when I add or remove one from my mail server.  It's not totally
> trivial but it's not that hard.
>
> I suppose we could encourage people to implement ed25519 signatures since
> the keys are small and more likely to fit in a single TXT record string
> for provisioning crudware that doesn't handle multiple strings, but beyond
> that, what do you have in mind?
>
>
I can't speak for Patrick, but I don't think he's necessarily thinking of
different encryption algorithms here.

Not all who wish to have their email DKIM signed have the luxury that you
have John of full control of the DKIM signing process. I'm specifically
thinking of the entity (call them Marty Marketer) who has the authority to
employ a third party to send authenticated mail on behalf of a domain, mail
that the third party can and will DKIM sign using the entity's domain.
Sadly, Marty does not have the authority to update DNS for that domain in
order to publish a DKIM public key. This leads to challenges as the third
party presents to Marty a public key to publish, and Marty tries to figure
out to whom to pass along this information and in what format. This leads
to screen caps, or cutting and pasting errors, misdirected mail chains,
etc., etc.

Is this the way it should be? Probably not, but it's a reality for many,
and it's a problem we don't as an industry have an answer for yet. If we
did, there wouldn't be people in the other thread reporting such a high
percentage of DKIM failures due to malformed/missing keys.

Now, of course we could argue that Marty shouldn't be left to their own
devices to engage third party senders, and that should solely be the
province of the IT staff that manages DNS, but I fear that the energy
required to type and distribute such words would be wasted.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 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

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

[Douglas Foster]

Currently, domain owners can disable SPF by removing their SPF policy,
which can run into the problems that you raise, with evaluators that only
understand SPF.But providing an authentication selector in the DMARC
policy would remedy that risk.  Evaluators who understand DMARC would use
the new DMARC policy clauses to ignore SPF, but the domain owner could
still publish an SPF policy as a fallback authentication mechanism for
those evaluators who are rudimentary.

Fixing SPF:

SPF purports to tell two things:
- which server organizations are allowed to send on my behalf, and
- which servers within those organizations have that authorization

The intra-organization filter provides more granularity, but creates all of
the SPF complexity.  I suggest that intra-organization filtering is the
responsibility of the server organization, not the evaluator.

A simpler rule would be to specify the server domains that are allowed to
send on my behalf.   A message is authenticated for SPF when the server
domain (HELO or REVDNS) is in the authorized domain list and the server
host name is forward-confirmed to the Source IP.   Nested includes would
not be needed, and policies would not be excessively complex.

DF


On Tue, Jun 20, 2023 at 5:12 AM Tobias Herkula 
wrote:

> 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.
>
>
>
> / 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
>
>
>
> 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 would be *great* if domain owners could assert via
> their DMARC record that receivers should only trust DKIM-signed email.
>
>
>
> Can these senders not accomplish the same thing by removing the SPF record
> altogether?
>
>
>
> -MSK, participating
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Tobias Herkula]

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.

/ 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

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 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 record that receivers 
should only trust DKIM-signed email.

Can these senders not accomplish the same thing by removing the SPF record 
altogether?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

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 publish a limited, dedicated IP range per tenant only, I do not see the 
current problem we have with SPF, when it comes to use SPF as identity 
anchor for email authentication, go away in the future.



On the other hand, there are domains whose mail is sent from a small number of 
IPs, exclusively used by such domain's dedicated servers.  SPF works very well 
in those cases.


I'm well aware that the global tendency is to outsource anything IT, including 
mail.  However, I'd continue to support independent sending, avoiding to burn 
bridges behind us.  Gmail security team's proposal, to express allowed 
authentication mechanisms as a policy provides for the best possibilities.  We 
can do it also without a version bump.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[David Verdin]

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 
up-to-date SPF record, even if you have a very large number of customers 
: you only have one single record to maintain, which is not hard.


In addition, I'd hope to encourage any organization, including hosting 
comapnies, to know where their mail are supposed to be sent from. It 
looks like a minimum security knowledge to me.


Regards,

David

On 18/06/2023 23:06, Ken Simpson wrote:
On Sun, Jun 18, 2023 at 10:56 AM Douglas Foster 
 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.   Do they treat SPF NONE as acceptable or
suspicious?

For your situation Ken, do your clients have the ability to
connect their web-generated email to a DKIM signing server?   If
not, do you envision providing that service (with SPF AUTH login
to ensure clients are kept separate from each other))?


Most web hosting customers are simple SMBs - think restaurants, small 
shops, a car garage, etc. They have no idea what DKIM is, never mind 
having access to a DKIM signing server. 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.


Some transactional email providers provide a DKIM signing service with 
CNAME-based DKIM key hosting. That's a great concept and we may one 
day provide it with an API hook allowing the hosting providers to hook 
this up for their clients at scale.


Regards,
Ken
--

Ken Simpson

CEO, MailChannels 




Facebook  | Twitter  | 
LinkedIn | Help Center 



Our latest case study video: watch here! 



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et 
l'atteindre."
- Francis Blanche

David Verdin
Chef de Projet Collaboratif
Département PROduits NUMériques
Direction des Services Applicatifs
RENATER - Rennes


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Wei Chuang]

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, financial,
commercial and other senders to phishing attacks.  (Anecdotally we spot
checked some 10 financial companies for a different reason, and found 3 of
them were similarly vulnerable).  So it's really important to mitigate this
vulnerability from DMARCbis.  That said, we really want to emphasize that
SPF is still very useful and important for email authentication as it is a
rather important part of a portfolio of authentication signals for Gmail,
and has a complementary role to DKIM in our system.   In fact, our
forwarders guidance calls for supporting DKIM and SPF [2], and this is
really true for any traffic (forwarded or from some originator) to Gmail.

Our email authentication numbers roughly look similar to other large
senders.  Our DMARC percentages are as follows (queried over a week), and
qualified as accepted messages.

DmarcPolicy

count

REJECT

45.60%

absent

22.73%

NONE

18.78%

QUARANTINE

12.89%

100.00%

We then look at DKIM and SPF authentication rates (and independent of
DMARC).  The following numbers come from deeper in the delivery pipeline
after being accepted and evaluating DMARC policy.  We see that SPF provides
coverage for DKIM authentication gaps.  The following table shows the
percentage of messages with SPF pass (true/false) and RFC8601
 DKIM
authentication-results.  Of this traffic, DKIM is not passing for 5.56% and
there's SPF coverage for 4.78%.  A large cause for this is messages that
were not DKIM signed but could be validated with SPF at 3.91%.

ConcatSpfPassDkimAuthResults

SUM of

TRUE,PASS

92.58%

TRUE,NEUTRAL

3.91%

FALSE,PASS

1.85%

FALSE,NEUTRAL

0.72%

TRUE,FAIL

0.69%

TRUE,TEMPERROR

0.17%

FALSE,FAIL

0.05%

FALSE,TEMPERROR

0.02%

TRUE,POLICY

0.00%

FALSE,POLICY

0.00%

Grand Total

100.00%

When we break up this traffic by distinct domain counts, the view is
different.  There notably appears to be many more senders for DKIM than SPF
which is surprising (DKIM: 73.26%, SPF 35.34%).  We haven't analyzed this
further but there may be many more DKIM capable senders than previously
thought.  Unfortunately one hypothesis is that many of these senders are
spammers that are able to use authentication more proactively than regular
senders.  Even so, the DKIM not passing rate is 26.74%, and SPF can provide
coverage for 17.41%.

ConcatSpfPassDkimAuthResults

SUM of

FALSE,PASS

55.33%

TRUE,PASS

17.93%

TRUE,NEUTRAL

15.30%

FALSE,NEUTRAL

7.58%

TRUE,FAIL

1.09%

TRUE,TEMPERROR

0.98%

FALSE,FAIL

0.97%

FALSE,TEMPERROR

0.76%

TRUE,POLICY

0.04%

FALSE,POLICY

0.02%

Grand Total

100.00%

Because from these numbers, we can see that SPF does provide significant
coverage when DKIM is not present, so we need to find a bridging process if
we are to move to DKIM-only for DMARCbis.  Our proposal would be for
DMARCbis to maintain the default for SPF and DKIM support, and to support
senders that want to drop SPF as one of their DMARC authentication methods
to avoid the SPF upgrade vulnerability.  We could have a DMARC policy tag
for authentication e.g. "auth=" that describes the permitted authentication
methods the sender supports and receiver MUST use for validation.   DKIM or
SPF are represented as tags "dkim" and "spf", and if multiple tags are
present then they are comma separated and any one passing is considered
passing authentication.  Also at least one authentication method MUST be
present.  Other authentication methods could be added in the future as it
is our hope that there will be some other authentication method to improve
upon and someday replace SPF.  overall.  If "auth=" is missing, then DMARC
falls back to supporting SPF and DKIM.

The proposed deployment process would be that senders at higher risk from
>From header spoofing will invest in deploying DKIM and will declare
authentication as DKIM-only.  SMB senders can still bootstrap their DMARC
deployment by using SPF but hopefully will lower their risk by avoiding the
SPF include policy patterns described in [1].  In order to bring together
these new configurations over the long term, DMARCbis might want to define
a "DMARC2" configuration that symbolically defines the end authentication
goal e.g. it might be the "retirement" of SPF.

-Wei on behalf of the Gmail security team

[1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
[2]
https://support.google.com/mail/answer/175365?sjid=1196932423118655843-NA

On Mon, Jun 19, 2023 at 11:42 AM Patrick Ben Koetter  wrote:

> * 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