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

[Neil Anuskiewicz]

> 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 domain's SPF record.  I understand that in theory, it shouldn't matter, but 
> in practice it is.
> 
> Software engineering isn't a perfect science.  In general, a more complex 
> protocol will suffer more defects.  If you want to design things that only 
> work when software is perfect, I'm not interested.
> 
> In terms of utility for direct connections, I think having both helps and I 
> don't find claims the SPF can never pass when DKIM fails to be credible.  If 
> someone has data that shows that's true now, I'd be interested to see it (my 
> experience is a few years ago, so things may have changed).
> 
> Ultimately, I think SPF and DKIM both suffer from what I'll genetically call 
> data hygiene problems.  SPF is mostly adding third party providers who are 
> insufficiently careful (might not even care, I don't know) generating SPF 
> pass results for "bad" mail.  DKIM is mostly about replay attacks.  Neither 
> of these are protocol problems and I don't think support dumping one or the 
> other out of DMARC.
> 
> One could make the opposite argument too, and I think it would be equally 
> valid:
> 
> The only value DKIM brings for DMARC is for indirect mail flows.  For any 
> direct connections, SPF is sufficient.  All the proposed DKIM changes to 
> solve the DKIM replay problem are likely to break indirect mail flows anyway, 
> so there's no longer a point to keep DKIM.  It's much more complicated and it 
> looks like the benefit of it is going away, let's just simplify the protocol 
> and get rid of it.
> 
> Now, I think that's a bad argument, but I don't think it's any worse than the 
> argument being presented to get rid of SPF.

I’ve observed the pattern of a high dmarc pass rate on DKiM alone, over 99% in 
most cases, yet as cogently stated by others, SPF will take a 99.5% pass rate 
to a rock solid 100%.

These might be an acceptable amount of blocked mail in some situations but 
there are many other scenarios where these lost emails, which add up fast, cost 
the company money and potentially strain relationships.  Email is perhaps the 
most important tool for business communication between businesses. An account 
manager sends a contract to an important prospect who doesn’t get it. That’s 
the cost. It might not be your first day at 99.9% but that number is on a 
rendezvous with its destiny to cost the business and individuals in various 
ways.

The effects of what seem to be small but aren’t when it comes to communication 
in business. 

Sure, we narrow the scope of our spf as much as we possibly can but we don’t 
toss that 0.5% traffic away without a reasonably good reason. 

If someone can cogently explain the assumption that the costs of spf 
implantation done judiciously (You don’t put an ESPs entire include in your org 
domain’s spf but you don’t just punt, declining the benefits of well implanted 
SPF. That’s an unforced error. Sometimes you have to throw SPF overboard but 
that’s not optimal. I get the feeling some here might make spf walk the plank 
right away. I ask that you reconsider that notion.
___
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

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 

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

[Patrick Ben Koetter]

* 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
> others here have obtained on smaller samples.  However small, it may confer
> to SPF the role of a stabilizer in DMARC mail flows.

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. To me SPF destabilizes
email authentication. It should not be used in future version of DMARC anymore.

But why is it so many hang to SPF?

My personal experience as a consultant is many domain owners prefer SPF over
DKIM because SPF is easier to implement. They don't care about the one being
the superior identity anchor to the other. They want to send. They want
deliverability. And they want to get it done as soon as possible at the least
investment. Business. Efficency.

As long as I can think of generating and handling DKIM keys has been a pain.
There's SHA1 and SHA256, then RSA and ED25519, then there's quite a variety of
flags to publish (test mode, email usage only, ...) and even if you managed to
get all of that right you are likey to fail when it comes to publish the DNS
TXT record. It's overly long requires multiline quoting etc. pp. and I've seen
experienced DNS operators fail repeatedly to get it right at first attempt.

Many get publishing DKIM keys wrong, but that doesn't hurt them as long as SPF
passes during DMARC authentication. They can send. They get deliverability.
Why bother with DKIM problems?

If we drop SPF in DMARCv2 SPF in all its dominance will suddenly be absent and
DKIM with all its implementational problems will suddenly be fully exposed.
And people will suddenly be forced to implement DKIM and suffer from all the
pain I've described above. I do expect them to be not amused - to put it
friendly.

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.

p@rick


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

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

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

[Alessandro Vesely]

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 authentication was conceived exactly because end users have a hard 
time trying to understand authentication mechanisms.  Hosting providers who 
cannot do DKIM, on the other hand, are certainly not professional.




Some transactional email providers provide a DKIM signing service with 
CNAME-based DKIM key hosting.



This trick is used when the signing server is detached from DNS.  They create a 
public key and publish it under their own domain, then ask the user to publish 
a CNAME pointing to it.  The user could have published the public key directly. 
 The need to resort to pointers stems from difficulties in publishing long RSA 
keys, which required to increase the maximum length of TXT data in some DNS web 
forms.



Best
Ale
--





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

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

[Barry Leiba]

> 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 read and
understand the DMARC spec:

A receiver that implements DMARC will look at the domain name in the
message's "From" header field and will retrieve the DMARC policy
record from that domain.  If the record says, for example, "p=reject",
and there is no SPF or DKIM authentication that matches that domain
name, that means that the receiver is being asked *not* to deliver the
message, but instead to reject it (whether the receiver does so or not
depends upon their own policy).

Now, of course, a sender that uses neither SPF nor DKIM on its
legitimate mail would be foolish to use a "p=reject" DMARC policy.
But if a spammer pretends to be them and tries to sneak by, well, as I
said, that's exactly what DMARC is intended to deal with.

Barry

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

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

[Ken Simpson]

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

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

[Jan Dušátko]

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 take advantage of this and just won't add a digital signature (I 
miss ADSP, I liked this standard). SPF at least to some extent limits 
where this e-mail can leave from.
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?). And the basic problem is just how to give the recipient of 
e-mails from the organization the tools to verify. Because it's nothing 
but authenticity verification. No one else can define this policy. 
Because there are cases where each of these methods has a legitimate 
use. But at the moment, trying to provide exhaustive information that 
the recipient could verify is extremely challenging.
Such a policy must be unambiguous, it must not allow undefined behavior 
... that is, I'm getting to the status machine. The policy conditions 
are not met, that is, the e-mail is rejected or falls into quarantine. 
In my opinion, DMARC2 is a good way to solve some problems, but I would 
personally like to see the possibility of specifying control mechanisms 
based on the owner's decision. I would also like to see a specification 
of what quarantine means. It's marking, moving into user or system 
quarantine, deteriorating scores ... Likewise, I would leave it up to 
the recipient to carry out the controls. It's in his interest, but it's 
his decision.


Thank you

Jan

Dne 18. 6. 2023 v 19:56 Douglas Foster napsal(a):

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))?

DF

On Sat, Jun 17, 2023 at 5:39 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.
While one option would be to allow the specification within the DMARC
record of acceptable authentication methods, removing SPF altogether would
be more straightforward.

Domain owners constantly struggle to keep their SPF records up to date.
Errors are easy to make, and the consequences of a mistake can be grave,
particularly for domains that are a frequent target of phishing gangs.

At least with DKIM, domain owners can take charge of their authentication
rather than delegating any part of it to third parties (for instance, via
spf include records).

Regards,
Ken

On Sat, Jun 17, 2023 at 11:25 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:


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 ambiguity, users cannot be expected to do better with less information.
Domain-specific tolerance for risk needs to be implemented with
domain-specific policies, but not with end-user discretion.

DMARC has limited scope.  In its purest form, it only blocks
impersonations when the domain has a DMARC policy, the policy specifies
enforcement (quarantine or reject), and the policy is detected correctly
(absence of PSL errors and absence of in-transit changes).   Only a subset
of domains have a DMARC policy, and only a subset of those domains have
enforcement. So only a small percentage of impersonation attacks can be
protected by DMARC.  For that very limited defense to work, domain owners
and evaluators need a high level of confidence in a PASS result.
Eliminating the PSL increases the confidence in PASS even if it creates
some increase in false failures.   Eliminating SPF will have the same
effect, and is desirable for the same reason.   Our assumption is that
DMARC-enforcing domain owners are highly motivated and will reconfigure as
necessary to ensure DMARC PASS results.

This same logic raises questions about whether relaxed authentication
remains necessary or appropriate.  With SPF, relaxed authentication seems
necessary because changing the MailFrom domain to match a desired From
domain is complex.   For DKIM, I see no important obstacles which prevent

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

[Douglas Foster]

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))?

DF

On Sat, Jun 17, 2023 at 5:39 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.
> While one option would be to allow the specification within the DMARC
> record of acceptable authentication methods, removing SPF altogether would
> be more straightforward.
>
> Domain owners constantly struggle to keep their SPF records up to date.
> Errors are easy to make, and the consequences of a mistake can be grave,
> particularly for domains that are a frequent target of phishing gangs.
>
> At least with DKIM, domain owners can take charge of their authentication
> rather than delegating any part of it to third parties (for instance, via
> spf include records).
>
> Regards,
> Ken
>
> On Sat, Jun 17, 2023 at 11:25 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> 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 ambiguity, users cannot be expected to do better with less information.
>> Domain-specific tolerance for risk needs to be implemented with
>> domain-specific policies, but not with end-user discretion.
>>
>> DMARC has limited scope.  In its purest form, it only blocks
>> impersonations when the domain has a DMARC policy, the policy specifies
>> enforcement (quarantine or reject), and the policy is detected correctly
>> (absence of PSL errors and absence of in-transit changes).   Only a subset
>> of domains have a DMARC policy, and only a subset of those domains have
>> enforcement. So only a small percentage of impersonation attacks can be
>> protected by DMARC.  For that very limited defense to work, domain owners
>> and evaluators need a high level of confidence in a PASS result.
>> Eliminating the PSL increases the confidence in PASS even if it creates
>> some increase in false failures.   Eliminating SPF will have the same
>> effect, and is desirable for the same reason.   Our assumption is that
>> DMARC-enforcing domain owners are highly motivated and will reconfigure as
>> necessary to ensure DMARC PASS results.
>>
>> This same logic raises questions about whether relaxed authentication
>> remains necessary or appropriate.  With SPF, relaxed authentication seems
>> necessary because changing the MailFrom domain to match a desired From
>> domain is complex.   For DKIM, I see no important obstacles which prevent
>> the signature domain  from exactly matching the From domain.
>>
>> ARC addresses the one problem that domain owners cannot prevent, which is
>> forwarding with in-transit changes.
>>
>> Evaluators and recipients have a much larger problem.  They need to
>> protect themselves from all impersonation attacks, which DMARC does not
>> attempt.   Their defenses must be implemented within the limits of
>> information available at evaluation time.   If the message has a relevant
>> DKIM signature but no DMARC policy, the DKIM PASS is still a valid
>> indication that the message is not impersonated.   Similarly, if the
>> message has no signature but produces SPF PASS with exact alignment, the
>> SPF PASS result indicates that the message is probably not impersonated.
>> Conversely, SPF FAIL and SPF NONE service to increase the suspicion of an
>> impersonation.
>>
>> Evaluators use sender authentication to perform a three-way split on
>> messages:
>> - Messages from verified and highly trusted senders are allowed to bypass
>> some or all content filtering.
>> - Messages from unwanted senders are unconditionally blocked prior to
>> content filtering.
>> - Messages from all other senders are accepted if they pass content
>> filtering.
>>
>> The more effective your sender authentication, the less you need perfect
>> content filtering.   Similarly, the more perfect your content filtering,
>> the less you need optimal sender authentication.
>>
>> In summary, your instincts are correct, SPF has a long term role in your
>> defenses, even if it is not part of the DMARC specification.
>>
>> Doug Foster
>>
>> On Sat, 

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

[Hector Santos]

> 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? Failure 
>> if any are missing?
> 
> No, that has never been the case.  Please reread RFC 7489.
> 



Everything in that doc, all angles of reading this Informational Status RFC 
suggest SPF is a natural part of the DMARC consideration.  

A domain with a DMARC1 record is expected to have SPF and DKIM.  The 
authenticated identifiers need to be aligned as well. The DMARC1 policy define 
how failures are handled.  If the policy p=none allows for failures by not 
having a SPF record, I would agree that would be technically true but not all 
receivers behave the same.With restrictive DMARC policies. SPF is pretty 
much required.  Senders risked failures by receivers who may applied it 
inconsistently. 

Section 4.3 has items 1,6, 7 and 8 describing SPF as a factor  in the 
established procedure and flow and consideration in policy result evaluation. 

Let’s consider the huge industry DMARC marketing as well where SPF, DKIM are 
described as necessary email security preparation for  DMARC.

The section 10.1, 2nd para confirms my main point that SPF may be processed 
separately for reject (-all)  results preempting payload processing:


   Some receiver architectures might implement SPF in advance of any
   DMARC operations.  This means that a "-" prefix on a sender's SPF
   mechanism, such as "-all", could cause that rejection to go into
   effect early in handling, causing message rejection before any DMARC
   processing takes place.  Operators choosing to use "-all" should be
   aware of this.


Anyway, I support removing SPF from the DMARCbis or DMARC2 evaluation.  Section 
10.1 2nd para semantics need to remain.

Thanks

—
HLS




___
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 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.  Please reread RFC 7489.

R's,
John

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

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

[Hector Santos]

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


Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure if 
any are missing?

Even then, with no SPF, what would remain for a reduced DMARC2 requirement is a 
1st party DKIM signature only.  No 3rd party. When we resolve this part, “I can 
die and finally go to heaven."

Note, from my pov, SPF was always separate from any payload DKIM-based policy 
protocol process because there are receivers who will reject at SMTP before 
DATA or DMARC consideration. For these optimized systems, DMARC would only ever 
see a SPF = pass, softfail, neutral or none/unknown but never a spf=reject 
unless the implementation delayed SPF rejects until DMARC can be processed.

—
HLS

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

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

[Murray S. Kucherawy]

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

[Ken Simpson]

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. While one option
would be to allow the specification within the DMARC record of acceptable
authentication methods, removing SPF altogether would be more
straightforward.

Domain owners constantly struggle to keep their SPF records up to date.
Errors are easy to make, and the consequences of a mistake can be grave,
particularly for domains that are a frequent target of phishing gangs.

At least with DKIM, domain owners can take charge of their authentication
rather than delegating any part of it to third parties (for instance, via
spf include records).

Regards,
Ken

On Sat, Jun 17, 2023 at 11:25 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> 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 ambiguity, users cannot be expected to do better with less information.
> Domain-specific tolerance for risk needs to be implemented with
> domain-specific policies, but not with end-user discretion.
>
> DMARC has limited scope.  In its purest form, it only blocks
> impersonations when the domain has a DMARC policy, the policy specifies
> enforcement (quarantine or reject), and the policy is detected correctly
> (absence of PSL errors and absence of in-transit changes).   Only a subset
> of domains have a DMARC policy, and only a subset of those domains have
> enforcement. So only a small percentage of impersonation attacks can be
> protected by DMARC.  For that very limited defense to work, domain owners
> and evaluators need a high level of confidence in a PASS result.
> Eliminating the PSL increases the confidence in PASS even if it creates
> some increase in false failures.   Eliminating SPF will have the same
> effect, and is desirable for the same reason.   Our assumption is that
> DMARC-enforcing domain owners are highly motivated and will reconfigure as
> necessary to ensure DMARC PASS results.
>
> This same logic raises questions about whether relaxed authentication
> remains necessary or appropriate.  With SPF, relaxed authentication seems
> necessary because changing the MailFrom domain to match a desired From
> domain is complex.   For DKIM, I see no important obstacles which prevent
> the signature domain  from exactly matching the From domain.
>
> ARC addresses the one problem that domain owners cannot prevent, which is
> forwarding with in-transit changes.
>
> Evaluators and recipients have a much larger problem.  They need to
> protect themselves from all impersonation attacks, which DMARC does not
> attempt.   Their defenses must be implemented within the limits of
> information available at evaluation time.   If the message has a relevant
> DKIM signature but no DMARC policy, the DKIM PASS is still a valid
> indication that the message is not impersonated.   Similarly, if the
> message has no signature but produces SPF PASS with exact alignment, the
> SPF PASS result indicates that the message is probably not impersonated.
> Conversely, SPF FAIL and SPF NONE service to increase the suspicion of an
> impersonation.
>
> Evaluators use sender authentication to perform a three-way split on
> messages:
> - Messages from verified and highly trusted senders are allowed to bypass
> some or all content filtering.
> - Messages from unwanted senders are unconditionally blocked prior to
> content filtering.
> - Messages from all other senders are accepted if they pass content
> filtering.
>
> The more effective your sender authentication, the less you need perfect
> content filtering.   Similarly, the more perfect your content filtering,
> the less you need optimal sender authentication.
>
> In summary, your instincts are correct, SPF has a long term role in your
> defenses, even if it is not part of the DMARC specification.
>
> Doug Foster
>
> On Sat, Jun 17, 2023 at 8:28 AM Jan Dušátko  40dusatko@dmarc.ietf.org> wrote:
>
>> 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
>> networks with mask /8 or /16 is extremely inappropriate
>> - It is not possible to set up the enforcement of DKIM signatures
>> because DomainKey and its policies are not related to DKIM and there is
>> no similar technology for DKIM (ADSP is not used)
>> - If I 

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

[Douglas Foster]

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 ambiguity, users cannot be expected to do better with less information.
Domain-specific tolerance for risk needs to be implemented with
domain-specific policies, but not with end-user discretion.

DMARC has limited scope.  In its purest form, it only blocks impersonations
when the domain has a DMARC policy, the policy specifies enforcement
(quarantine or reject), and the policy is detected correctly (absence of
PSL errors and absence of in-transit changes).   Only a subset of domains
have a DMARC policy, and only a subset of those domains have enforcement.
So only a small percentage of impersonation attacks can be protected by
DMARC.  For that very limited defense to work, domain owners and evaluators
need a high level of confidence in a PASS result.  Eliminating the PSL
increases the confidence in PASS even if it creates some increase in false
failures.   Eliminating SPF will have the same effect, and is desirable for
the same reason.   Our assumption is that DMARC-enforcing domain owners are
highly motivated and will reconfigure as necessary to ensure DMARC PASS
results.

This same logic raises questions about whether relaxed authentication
remains necessary or appropriate.  With SPF, relaxed authentication seems
necessary because changing the MailFrom domain to match a desired From
domain is complex.   For DKIM, I see no important obstacles which prevent
the signature domain  from exactly matching the From domain.

ARC addresses the one problem that domain owners cannot prevent, which is
forwarding with in-transit changes.

Evaluators and recipients have a much larger problem.  They need to protect
themselves from all impersonation attacks, which DMARC does not attempt.
Their defenses must be implemented within the limits of information
available at evaluation time.   If the message has a relevant DKIM
signature but no DMARC policy, the DKIM PASS is still a valid indication
that the message is not impersonated.   Similarly, if the message has no
signature but produces SPF PASS with exact alignment, the SPF PASS result
indicates that the message is probably not impersonated.   Conversely, SPF
FAIL and SPF NONE service to increase the suspicion of an impersonation.

Evaluators use sender authentication to perform a three-way split on
messages:
- Messages from verified and highly trusted senders are allowed to bypass
some or all content filtering.
- Messages from unwanted senders are unconditionally blocked prior to
content filtering.
- Messages from all other senders are accepted if they pass content
filtering.

The more effective your sender authentication, the less you need perfect
content filtering.   Similarly, the more perfect your content filtering,
the less you need optimal sender authentication.

In summary, your instincts are correct, SPF has a long term role in your
defenses, even if it is not part of the DMARC specification.

Doug Foster

On Sat, Jun 17, 2023 at 8:28 AM Jan Dušátko  wrote:

> 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
> networks with mask /8 or /16 is extremely inappropriate
> - It is not possible to set up the enforcement of DKIM signatures
> because DomainKey and its policies are not related to DKIM and there is
> no similar technology for DKIM (ADSP is not used)
> - If I am the administrator of hundreds or thousands of domains, it is
> in my interest to provide the recipient with information about the
> sender's authentication options. For example, all emails use DKIM, all
> emails use ARC, all emails use SPF ... and if not, you can discard them.
> But I do not have this option with DMARC.
> I understand that this is in the middle of what DMARC2 is supposed to
> address. But could there be a possibility for the DMARC2 record
> administrator to define a policy for domains and provide relevant
> information for recipients? It is the recipient's decision whether to do
> this verification, but it is also the sender's decision to offer this
> information. Unfortunately, at this point, either the signature is
> valid, or wrong, or it is not. If it is not possible to accept the
> e-mail, but the recipient does not have the option of verifying whether
> the sender's domain enforces this signature. It is similar with SPF. And
> DMARC2 seems to me to be a good place for these definitions. But I would
> like to avoid of forced removal of SPF, please let it for administrator
> decision.
>
> Regards
>
> Jan
>
> Dne 16. 6. 2023 v 13:28 

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

[Jan Dušátko]

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 
networks with mask /8 or /16 is extremely inappropriate
- It is not possible to set up the enforcement of DKIM signatures 
because DomainKey and its policies are not related to DKIM and there is 
no similar technology for DKIM (ADSP is not used)
- If I am the administrator of hundreds or thousands of domains, it is 
in my interest to provide the recipient with information about the 
sender's authentication options. For example, all emails use DKIM, all 
emails use ARC, all emails use SPF ... and if not, you can discard them. 
But I do not have this option with DMARC.
I understand that this is in the middle of what DMARC2 is supposed to 
address. But could there be a possibility for the DMARC2 record 
administrator to define a policy for domains and provide relevant 
information for recipients? It is the recipient's decision whether to do 
this verification, but it is also the sender's decision to offer this 
information. Unfortunately, at this point, either the signature is 
valid, or wrong, or it is not. If it is not possible to accept the 
e-mail, but the recipient does not have the option of verifying whether 
the sender's domain enforces this signature. It is similar with SPF. And 
DMARC2 seems to me to be a good place for these definitions. But I would 
like to avoid of forced removal of SPF, please let it for administrator 
decision.


Regards

Jan

Dne 16. 6. 2023 v 13:28 Sebastiaan de Vos napsal(a):
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 standard.


Is it not in our best interest to encourage and motivate in particular 
the less sophisticated senders to use the higher confidence mechanisms?



On 16.06.23 13:02, Douglas Foster wrote:
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 impersonated, but they do not provide an equal level 
of confidence.


Unsophisticated senders have little incentive to use the higher 
confidence mechanisms because any PASS result is still PASS.  The 
solution is not to pretend that SPF is worthless, because that is an 
overstatement.   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 distrusted by some 
evaluators.


Similarly, needs multiple types of FAIL.   Since the data indicates 
that missing (or invalid) public keys are a significant portion of 
all failures, it needs a separate failure code from "normal" failures 
which suggest in-transit changes.  The DKIM group needs to define the 
result code but this group would need to integrate it into our 
aggregate reports.





--
-- --- - -
Jan Dušátko

Tracker number: +420 602 427 840
e-mail: j...@dusatko.org
GPG Signature:  https://keys.dusatko.org/E535B585.asc
GPG Encrypt:https://keys.dusatko.org/B76A1587.asc

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

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

[Michael Kliewe]

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 misplaced confidence in SPF currently 
weakens the whole DMARC standard.


Exactly.

There are rare bugs in DKIM software (signer or verifier) that only were 
fixed recently. These bugs have been there for years, but nobody noticed 
them because of the "SPF safety net" in DMARC. SPF is hiding bugs in 
DKIM software.


The SPF safety net has holes/problems, like:

- "I include 7 different big ESPs into my SPF record", which results in 
millions of IPs
- or "I put my whole cloud IP range into my SPF record to be sure that 
my future IPs that I might get are already in it",
- or when switching the mail provider, only add the new IP at the new 
provider, but don't remove the old IP of the old provider. Then some 
lucky guy will get/reuse that old IP sooner or later...

- or "+all"
- or: If you have an ESP which puts multiple customers on one outbound 
IP ("shared infrastructure"), then all customers who are on the same IP 
can send mails with all the other domains on that IP. The same with mail 
relays on "standard web hosters": Lots of them don't check the 
Envelope-From or From-Header, they just relay all mails to the Internet. 
Every customer can send mails with the domains of all other customers, 
and you get an SPF=pass.
- "my mails fail DKIM, but I have the safety net SPF, so everything is 
fine, I don't need to fix DKIM". They forget that all those mails will 
fail SPF/DMARC if they are being forwarded (indirect mailflow).


You can argue that SPF helps as a safety-net to DKIM (but only on 
"direct mailflows"), but you also have lots of problems in DMARC because 
of SPF.


You don't need a half-broken safety net to DKIM if you concentrate on 
fixing the DKIM bugs, like bugs in DKIM software (signer+verifier) or 
fixing bugs in DKIM deployments like missing/wrong DKIM DNS records, or 
not DKIM-signing your bounce mails (default behaviour of Postfix, 
locally generated bounce-mails are not processed by milters).


If everyone on this mailing list can generate a list of DKIM signatures 
which are failing often, but should not fail, and contact those top 20 
or top 50 domains, then I guess 95% of the total mail volume with DKIM 
problems will be fixed, and you can get rid of the SPF safety net that 
you don't need anymore in DMARC (you might still use SPF later in the 
analysis as a "scoring/reputation/detection mechanism" or so, we are 
just talking about removing it from DMARC to reduce problems while 
calculating the DMARC result and detect sender forgery).


I don't know how BIMI will proceed, currently it relies on the DMARC 
result. But because of recent problems with Gmail and UPS, it looks like 
it's a good idea to only trust the DMARC result if it was based on the 
DKIM result. I found this statement from Google:


"This issue stems from a third-party security vulnerability allowing bad 
actors to appear more trustworthy than they are. To keep users safe, we 
are requiring senders to use the more robust DomainKeys Identified Mail 
(DKIM) authentication standard to qualify for Brand Indicators for 
Message Identification (blue checkmark) status."

https://www.theregister.com/2023/06/09/google_bimi_email_authentication/

...requiring senders to use the more robust DKIM authentication standard...

Which means: the SPF result is being ignored when evaluating BIMI, "DKIM 
only" is the way to go for sender authentication.


/M

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

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

[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 misplaced confidence in SPF currently weakens the 
whole DMARC standard.


Is it not in our best interest to encourage and motivate in particular 
the less sophisticated senders to use the higher confidence mechanisms?



On 16.06.23 13:02, Douglas Foster wrote:
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 impersonated, but they do not provide an equal level of 
confidence.


Unsophisticated senders have little incentive to use the higher 
confidence mechanisms because any PASS result is still PASS.   The 
solution is not to pretend that SPF is worthless, because that is an 
overstatement.   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 distrusted by some 
evaluators.


Similarly, needs multiple types of FAIL.   Since the data indicates 
that missing (or invalid) public keys are a significant portion of all 
failures, it needs a separate failure code from "normal" failures 
which suggest in-transit changes.   The DKIM group needs to define the 
result code but this group would need to integrate it into our 
aggregate reports.


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

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

[Alessandro Vesely]

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 distrusted by some evaluators.


SPF reliability is not something that an evaluator can automatically learn, at 
least not straightforwardly.  Overbloated SPF settings can make impersonation 
possible, thereby betraying DMARC intent.  Concerned domains should be advised 
to not include such stuff in their SPF record.


If someone set +all in their SPF record, then anyone is authorized to send mail 
on their behalf.  It is not an evaluator's job to syndicate their policy.  The 
problem arises if —as someone voiced— there are cases where a domain is somehow 
forced to publish a bloated SPF record, yet doesn't want to be freely 
impersonated and seeks DMARC protection.  Do such cases exist?



Best
Ale
--










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

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

[Douglas Foster]

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 impersonated, but they do not provide an equal level of
confidence.

Unsophisticated senders have little incentive to use the higher confidence
mechanisms because any PASS result is still PASS.   The solution is not to
pretend that SPF is worthless, because that is an overstatement.   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 distrusted by some evaluators.

Similarly, needs multiple types of FAIL.   Since the data indicates that
missing (or invalid) public keys are a significant portion of all failures,
it needs a separate failure code from "normal" failures which suggest
in-transit changes.   The DKIM group needs to define the result code but
this group would need to integrate it into our aggregate reports.








On Fri, Jun 16, 2023 at 5:52 AM Sebastiaan de Vos  wrote:

>
> > 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 rather consider that a de-stabiliser. From what I
> understand, SPF is part of the problem, not part of the solution.
>
> Sebastiaan
>
> ___
> 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] DMARC2 & SPF Dependency Removal

[Sebastiaan de Vos]

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 rather consider that a de-stabiliser. From what I 
understand, SPF is part of the problem, not part of the solution.


Sebastiaan

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

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 
others here have obtained on smaller samples.  However small, it may confer to 
SPF the role of a stabilizer in DMARC mail flows.



Best
Ale
--





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

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

[Murray S. Kucherawy]

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
> >
> > This is staggering.  Can you characterize what the most common
> malformations
> > are?
>
> I think most of those are missing keys. I.e., there is no key in the
> dns at all for that header.d and header.s.
>

Oh, I thought "invalid" here meant a record was found and retrieved but was
found to be syntactically invalid.  That's rather a different story.

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

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

[Scott Kitterman]

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
> bigger both in DKIM and SPF.
> 
> Following statistics is random subset of emails going through iki.fi
> system, from last 30 days, consisting bit less than 4 million emails.
> Iki.fi is email forwarding service, so about 90% of those emails will
> fail SPF checks after iki.fi sends them forward. DKIM will go through
> unmodified, and we do not modify normal messages (spam messages might
> get tagged as spam depending on the members configuration), so 85.75%
> of emails will still have valid DKIM signature after passing iki.

Thanks.  Sorry for the late reply, I've been tied up with some other work the 
last couple of days.

I'm not surprised it's radically different as it's a differently scoped data 
set.  As I mentioned up-thread these were for directly connected mail 
deliveries, so the normal DMARC failure mechanisms weren't relevant.  
Additionally, these were mail servers for domains which were actively working 
on having a complete/correct DKIM/SPF configuration to support DMARC, so not 
average in that manner either.

Since all we had were statistics based on DMARC feedback, we were never able 
to explore what was behind the DKIM failure rate.

Often in large entities, it's the compartmentalization and need for 
coordination that turns out to cause many of the problems.  I've worked with 
companies on DMARC deployments where helping them update or develop relevant 
internal policy, procedures, and processes ended up being a significant 
fraction of the effort.  SPF, DKIM, and DMARC introduce a requirement for a 
more centralized and complete view of outbound architecture than has 
historically been needed.

Scott K


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

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

[Tero Kivinen]

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 you would like to see cases where if there is
> both SPF and DKIM, the cases where the both, only one, or neither
> passed, and how many of those cases would be where dkim=fail, but
> spf=pass?

I rerun the statistics and yes, there is 0.84% cases where dkim
failed, but spf returned eithe pass, softfail or neutral.

There was also 1.12% cases where spf returned permerror but dkim
returned pass, and 1.26% cases where dkim returned pass and spf
returned fail, or softfail.

There is of course much bigger part of emails where there was no dkim,
but there was spf that passed (7.03%) or softfailed (1.08%).

Here are the actual numbers for DKIM and SPF result combinations:

DKIM & SPF combinations
===
78.62%  3133749 dkim=pass,spf=pass
7.03%   280239  dkim=none,spf=pass
4.68%   186634  dkim=pass,spf=none
3.85%   153543  dkim=none,spf=none
1.12%   44543   dkim=pass,spf=permerror
1.08%   43212   dkim=none,spf=softfail
0.82%   32821   dkim=fail,spf=pass
0.78%   30953   dkim=pass,spf=softfail
0.61%   24221   dkim=none,spf=fail
0.48%   19329   dkim=pass,spf=fail
0.43%   17120   dkim=none,spf=neutral
0.24%   9612dkim=fail,spf=none
0.06%   2320dkim=none,spf=permerror
0.06%   2214dkim=pass,spf=neutral
0.04%   1712dkim=none,spf=temperror
0.02%   995 dkim=fail,spf=fail
0.02%   924 dkim=fail,spf=softfail
0.02%   669 dkim=temperror,spf=pass
0.01%   360 dkim=missing,spf=missing
0.00%   199 dkim=temperror,spf=temperror
0.00%   196 dkim=fail,spf=neutral
0.00%   144 dkim=missing,spf=none
0.00%   119 dkim=pass,spf=temperror
0.00%   99  dkim=missing,spf=pass
0.00%   50  dkim=fail,spf=permerror
0.00%   38  dkim=missing,spf=softfail
0.00%   14  dkim=temperror,spf=none
0.00%   10  dkim=temperror,spf=softfail
0.00%   7   dkim=missing,spf=fail
0.00%   6   dkim=fail,spf=temperror
0.00%   6   dkim=missing,spf=neutral
0.00%   1   dkim=temperror,spf=fail
0.00%   1   dkim=missing,spf=temperror

I.e. 78.64% of time both DKIM and SPF passed.

I also calculated statistics for all DKIM, SPF, DMARC, and ARC
combinations, but there were so many of them that I do not include the
full list here but here is top 30 from that list:

Protocol combinations

37.74%  1504477 dkim=pass,spf=pass,dmarc=missing,arc=missing
25.37%  1011277 dkim=pass,spf=pass,dmarc=pass,arc=missing
10.96%  436838  dkim=pass,spf=pass,dmarc=none,arc=missing
3.46%   138083  dkim=none,spf=pass,dmarc=missing,arc=missing
2.15%   85799   dkim=pass,spf=none,dmarc=missing,arc=missing
2.00%   79739   dkim=pass,spf=none,dmarc=pass,arc=missing
1.96%   78279   dkim=none,spf=none,dmarc=missing,arc=missing
1.64%   65205   dkim=none,spf=pass,dmarc=none,arc=missing
1.60%   63758   dkim=pass,spf=pass,dmarc=missing,arc=pass
1.54%   61579   dkim=none,spf=pass,dmarc=pass,arc=missing
1.16%   46309   dkim=pass,spf=pass,dmarc=pass,arc=pass
1.09%   43529   dkim=none,spf=none,dmarc=fail,arc=missing
0.92%   36478   dkim=pass,spf=pass,dmarc=fail,arc=missing
0.79%   31298   dkim=none,spf=none,dmarc=none,arc=missing
0.56%   22504   dkim=none,spf=softfail,dmarc=missing,arc=missing
0.56%   22123   dkim=pass,spf=permerror,dmarc=missing,arc=missing
0.55%   21973   dkim=pass,spf=pass,dmarc=none,arc=pass
0.40%   15760   dkim=fail,spf=pass,dmarc=missing,arc=missing
0.37%   14855   dkim=none,spf=softfail,dmarc=fail,arc=missing
0.37%   14716   dkim=pass,spf=softfail,dmarc=missing,arc=missing
0.34%   13576   dkim=none,spf=fail,dmarc=missing,arc=missing
0.32%   12745   dkim=pass,spf=permerror,dmarc=none,arc=missing
0.31%   12348   dkim=pass,spf=softfail,dmarc=pass,arc=missing
0.26%   10290   dkim=none,spf=neutral,dmarc=missing,arc=missing
0.24%   9657dkim=pass,spf=permerror,dmarc=pass,arc=missing
0.23%   9367dkim=pass,spf=fail,dmarc=missing,arc=missing
0.20%   8121dkim=pass,spf=fail,dmarc=pass,arc=missing
0.20%   7785dkim=fail,spf=pass,dmarc=none,arc=missing
0.17%   6719dkim=pass,spf=none,dmarc=missing,arc=pass
0.16%   6248dkim=none,spf=pass,dmarc=fail,arc=missing

So 37% emails had dkim and 

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

[Tero Kivinen]

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.
> 
> 
> 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 you would like to see cases where if there is
both SPF and DKIM, the cases where the both, only one, or neither
passed, and how many of those cases would be where dkim=fail, but
spf=pass?

I will try to see if I can run the that check later.

> > 0.19%   7506none,pass
> > 0.15%   5910pass,none
> 
> How do you order DKIM signatures?

My understanding is that rspamd most likely uses the order of DKIM
signatures in the email body. On the other hand order does not matter,
as if ANY of the dkim checks pass, then the whole message passes. The
reason I printed out the combinations of different dkim results was to
show that there are cases where there is multiple dkim headers and
some of those pass and some fail.

I.e there were:

0.00%   4   pass,fail,fail,fail,fail
0.00%   2   pass,pass,pass,pass,pass,pass

I.e. four emails had five dkim records, four of them failing and one
passing, where another two one had six dkim records all passing. Most
of the emails had oly one dkim record, and those of which had two most
of them were so that both passed.
-- 
kivi...@iki.fi

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

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

[Tero Kivinen]

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 the most common malformations
> are?

I think most of those are missing keys. I.e., there is no key in the
dns at all for that header.d and header.s. 

This might be caused by having some internal machine doing the DKIM
signing but not publishing the actual DKIM records in the dns at all.

Sometimes there is another DKIM record that will pass like this:

ARC-Authentication-Results: i=1;
MTA-v4;
dkim=none ("invalid DKIM record") header.d=ernieball.com 
header.s=ci-ernieball header.b=XXX;
dkim=pass header.d=criticalimpactinc.com header.s=keyd header.b=XXX;
spf=pass (MTA-v4: XXX)

Sometimes there that was the only dkim record and then the final
result is fail:

ARC-Authentication-Results: i=1;
MTA-v4;
dkim=none ("invalid DKIM record") header.d=autostadium.fi header.s=x 
header.b=XXX;
spf=pass (MTA-v4: XXX)

Note, that those are not really failures, I calculated those error
messages from dkim=none result to the statistics, as it indicates that
there was DKIM record in email, but DKIM was not set properly, so in
sense it is DKIM error, but if I remember right DKIM specification
says that not having DKIM record, or having missing keys etc in dns
are no different from each other, so both are DKIM=none... 
-- 
kivi...@iki.fi

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

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

[Richard Clayton]

-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 transport layer after the
signature was calculated. Start by looking for patterns such as accented
characters in the Subject header field or the RFC5322 From header field
(where Unicode stand-alone accents have been amalgamated with the
character they affect as a single glyph) or for unusual sets of spaces
(where "invisible" Unicode values have been substituted)

better yet of course get hold of the original email before it was signed
and sent to you -- but spammers tend not to help you with that !

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZIo7EN2nQQHFxEViEQLmKwCZAW3bqT5sWhDx6qr+WZ38maKfOl4AoMLT
aM2bjkAMnzUEliPUKB1NW/ho
=w9W/
-END PGP SIGNATURE-

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

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

[Alessandro Vesely]

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 messages?  Are there cases of DKIM 
random failure salvaged by SPF?




0.19%   7506none,pass
0.15%   5910pass,none



How do you order DKIM signatures?


Thanks for the data

Best
Ale
--






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

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

[Seth Blank]

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. They’re public after all, and a human (and generally, multiple
humans) shouldn’t need to be in the critical path of getting a key from a
sending system UI and then getting it published properly in DNS.

My main point on this whole thread is there’s a lot of theory, but as
Tevo’s data shows, the reality of these deployments and their challenges is
far trickier.

I’m still working with Todd to bring our own data on SPF to the working
group.

Seth, as an individual

On Wed, Jun 14, 2023 at 11:10 Murray S. Kucherawy 
wrote:

> 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
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

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

[Murray S. Kucherawy]

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

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
results, or on outgoing messages, using aggregate reports.

My environment has a single MX performing DKIM checking, with essentially
zero mailing list traffic.
I also have a single MTA performing DKIM signing.
The signing server is a different software implementation than the checking
server.

For outgoing messages, I see no evidence of random failures.   All of the
reported DKIM failures appear to have explanations.

For incoming messages, I defined a unique configuration as the tuple of (
Helo Domain, MailFrom domain, and From domain ).  Then I looked at
verification percentages for signed messages from each tuple.The
results were interesting:

   - 92% of tuples, sending 89% of all signed messages, had 100%
   verification rates
   - 5% of tuples, sending 2% of all signed messages, had 0% verification
   rates
   - 3% of tuples, sending 9% of all signed messages, had a verification
   rate between these limits.
   - Of all messages with DKIM failures, 85% were authenticated using
   aligned SPF PASS.

These statistics are based on 100% of incoming messages, regardless of
subsequent disposition.

My conclusions:

   - SPF is a necessary supplement to DKIM.
   - DKIM can be reliable:   Most senders and receivers have 100% reliable
   DKIM implementations.
   - Senders with 100% failure rates appear to be playing games with DKIM.
Some of these may already be on my block list.  The rest should  be
   reviewed to see if they should be added to my block list.
   - The 5% with inconsistent results need further investigation.   Perhaps
   a server farm has one server that is generating wrong signatures.

Doug Foster


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 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 going through iki.fi
> system, from last 30 days, consisting bit less than 4 million emails.
> Iki.fi is email forwarding service, so about 90% of those emails will
> fail SPF checks after iki.fi sends them forward. DKIM will go through
> unmodified, and we do not modify normal messages (spam messages might
> get tagged as spam depending on the members configuration), so 85.75%
> of emails will still have valid DKIM signature after passing iki.
>
> We do graylisting of blacklisted ip-addresses, thus spammers that do
> not work around graylisting are not part of the statistics.
>
> There is significant amount of mailing lists going through iki, and
> quickly checking that 1.58% of emails going through has spf-errors,
> dkim signers or similar with domain name in form of list.domain or
> lists.domain, so that will cause some of the SPF and DKIM failures.
> Note, that this only counts cases where the domain name was used in
> the verification and printed in the logs i.e., only in error cases.
>
> As we are using ARC, and we add ARC-Authentication-Results header to
> all emails as first step when they come in, and I used those headers
> to generate these statistics.
>
> First some generic statistics:
>
> Number of ARC-header levels
> ===
> 95.61%  3811208 1
> 3.83%   152487  2
> 0.44%   17711   3
> 0.09%   35864
> 0.01%   460 5
> 0.01%   349 6
> 0.01%   207 7
> 0.00%   36  8
> 0.00%   15  9
> 0.00%   1   10
>
> Mailer
> ==
> 91.96%  3665744 MTA-v4
> 8.04%   320315  MTA-v6
> 0.00%   1   MSA
>
> So 3.83% of emails already had one ARC header, and 0.56% had more than
> one arc header, with exactly one email having 10
> ARC-Authentication-Results headers. Most of the emails do not have ARC
> headers.
>
> 92% of traffic came in using IPv4..
>
> Then lets compare DKIM, SPF, DMARC and ARC results
>
> DKIM summary results
> =
> 85.75%  3417541 pass
> 13.11%  522367  none
> 1.12%   44604   fail
> 0.02%   893 temperror
>
> SPF results
> =
> 86.50%  3447577 pass
> 8.78%   349947  none
> 1.89%   75137   softfail
> 1.18%   46913   permerror
> 1.12%   44553   fail
> 0.49%   19536   neutral
> 0.05%   2037temperror
>
> DMARC results
> =
> 62.82%  1243393 pass
> 30.99%  613478  none
> 6.05%   119800  fail
>

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

[Barry Leiba]

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 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 going through iki.fi
> system, from last 30 days, consisting bit less than 4 million emails.
> Iki.fi is email forwarding service, so about 90% of those emails will
> fail SPF checks after iki.fi sends them forward. DKIM will go through
> unmodified, and we do not modify normal messages (spam messages might
> get tagged as spam depending on the members configuration), so 85.75%
> of emails will still have valid DKIM signature after passing iki.
>
> We do graylisting of blacklisted ip-addresses, thus spammers that do
> not work around graylisting are not part of the statistics.
>
> There is significant amount of mailing lists going through iki, and
> quickly checking that 1.58% of emails going through has spf-errors,
> dkim signers or similar with domain name in form of list.domain or
> lists.domain, so that will cause some of the SPF and DKIM failures.
> Note, that this only counts cases where the domain name was used in
> the verification and printed in the logs i.e., only in error cases.
>
> As we are using ARC, and we add ARC-Authentication-Results header to
> all emails as first step when they come in, and I used those headers
> to generate these statistics.
>
> First some generic statistics:
>
> Number of ARC-header levels
> ===
> 95.61%  3811208 1
> 3.83%   152487  2
> 0.44%   17711   3
> 0.09%   35864
> 0.01%   460 5
> 0.01%   349 6
> 0.01%   207 7
> 0.00%   36  8
> 0.00%   15  9
> 0.00%   1   10
>
> Mailer
> ==
> 91.96%  3665744 MTA-v4
> 8.04%   320315  MTA-v6
> 0.00%   1   MSA
>
> So 3.83% of emails already had one ARC header, and 0.56% had more than
> one arc header, with exactly one email having 10
> ARC-Authentication-Results headers. Most of the emails do not have ARC
> headers.
>
> 92% of traffic came in using IPv4..
>
> Then lets compare DKIM, SPF, DMARC and ARC results
>
> DKIM summary results
> =
> 85.75%  3417541 pass
> 13.11%  522367  none
> 1.12%   44604   fail
> 0.02%   893 temperror
>
> SPF results
> =
> 86.50%  3447577 pass
> 8.78%   349947  none
> 1.89%   75137   softfail
> 1.18%   46913   permerror
> 1.12%   44553   fail
> 0.49%   19536   neutral
> 0.05%   2037temperror
>
> DMARC results
> =
> 62.82%  1243393 pass
> 30.99%  613478  none
> 6.05%   119800  fail
> 0.08%   1485temperror
> 0.06%   1244permerror
>
> ARC results
> =
> 91.66%  160268  pass
> 8.34%   14584   reject
>
> 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.
>
> The difference is that only 1.14% of emails had errors (fail, or
> temperror) in their DKIM signatures (most of those were because the
> email was from the mailing list that modified the body, but did not
> generate new DKIM header), compared to the 4.24% of emails having SPF
> failures (softfail, permerror, fail or temperror). Meaning there were
> much more emails that failed SPF than DKIM. Even if we ignore the
> softfails, we still have about double the emails failing (2.35%).
>
> Note, that the dmarc and arc statistics are not from all of the
> emails, it only includes those which actually had DMARC or ARC
> information. For dmarc this was about 50%, and for ARC it was only
> 4.3% of all emails.
>
> Here are some statistics abut the DKIM processing and the error cases.
> 76.75% had one DKIM signature, and over 20% had more than one
> signature. Here is number of DKIM signatures and their results, i.e.,
> 22.22% of emails had two DKIM signatures both passing, and 0.34% had
> one signature that passed, and another that failed etc:
>
> DKIM results
> ===
> 62.67%  2497633 pass
> 22.22%  885372  pass,pass
> 13.06%  520332  none
> 1.04%   41477   fail
> 0.34%   13353   pass,fail
> 0.19%   7506none,pass
> 0.15%   5910pass,none
> 0.07%   2635fail,fail
> 0.06%   2235pass,pass,pass
> 0.05%   2034

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

[Tero Kivinen]

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 going through iki.fi
system, from last 30 days, consisting bit less than 4 million emails.
Iki.fi is email forwarding service, so about 90% of those emails will
fail SPF checks after iki.fi sends them forward. DKIM will go through
unmodified, and we do not modify normal messages (spam messages might
get tagged as spam depending on the members configuration), so 85.75%
of emails will still have valid DKIM signature after passing iki.

We do graylisting of blacklisted ip-addresses, thus spammers that do
not work around graylisting are not part of the statistics.

There is significant amount of mailing lists going through iki, and
quickly checking that 1.58% of emails going through has spf-errors,
dkim signers or similar with domain name in form of list.domain or
lists.domain, so that will cause some of the SPF and DKIM failures.
Note, that this only counts cases where the domain name was used in
the verification and printed in the logs i.e., only in error cases.

As we are using ARC, and we add ARC-Authentication-Results header to
all emails as first step when they come in, and I used those headers
to generate these statistics.

First some generic statistics:

Number of ARC-header levels
===
95.61%  3811208 1
3.83%   152487  2
0.44%   17711   3
0.09%   35864
0.01%   460 5
0.01%   349 6
0.01%   207 7
0.00%   36  8
0.00%   15  9
0.00%   1   10

Mailer
==
91.96%  3665744 MTA-v4
8.04%   320315  MTA-v6
0.00%   1   MSA

So 3.83% of emails already had one ARC header, and 0.56% had more than
one arc header, with exactly one email having 10
ARC-Authentication-Results headers. Most of the emails do not have ARC
headers.

92% of traffic came in using IPv4..

Then lets compare DKIM, SPF, DMARC and ARC results

DKIM summary results
=
85.75%  3417541 pass
13.11%  522367  none
1.12%   44604   fail
0.02%   893 temperror

SPF results
=
86.50%  3447577 pass
8.78%   349947  none
1.89%   75137   softfail
1.18%   46913   permerror
1.12%   44553   fail
0.49%   19536   neutral
0.05%   2037temperror

DMARC results
=
62.82%  1243393 pass
30.99%  613478  none
6.05%   119800  fail
0.08%   1485temperror
0.06%   1244permerror

ARC results
=
91.66%  160268  pass
8.34%   14584   reject

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.

The difference is that only 1.14% of emails had errors (fail, or
temperror) in their DKIM signatures (most of those were because the
email was from the mailing list that modified the body, but did not
generate new DKIM header), compared to the 4.24% of emails having SPF
failures (softfail, permerror, fail or temperror). Meaning there were
much more emails that failed SPF than DKIM. Even if we ignore the
softfails, we still have about double the emails failing (2.35%).

Note, that the dmarc and arc statistics are not from all of the
emails, it only includes those which actually had DMARC or ARC
information. For dmarc this was about 50%, and for ARC it was only
4.3% of all emails. 

Here are some statistics abut the DKIM processing and the error cases.
76.75% had one DKIM signature, and over 20% had more than one
signature. Here is number of DKIM signatures and their results, i.e.,
22.22% of emails had two DKIM signatures both passing, and 0.34% had
one signature that passed, and another that failed etc:

DKIM results
===
62.67%  2497633 pass
22.22%  885372  pass,pass
13.06%  520332  none
1.04%   41477   fail
0.34%   13353   pass,fail
0.19%   7506none,pass
0.15%   5910pass,none
0.07%   2635fail,fail
0.06%   2235pass,pass,pass
0.05%   2034none,none
0.03%   1296pass,pass,pass,pass
0.03%   1026pass,pass,fail
0.03%   1002fail,pass
0.02%   892 temperror
0.02%   631 pass,fail,fail
0.01%   583 pass,none,none
0.01%   369 fail,fail,fail
0.01%   356 fail,fail,pass
0.01%   335 

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

[Barry Leiba]

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 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 meaning (i.e., "this is a new message").  If that
> > insertion is happening in transport, then a local mailbox convention is
> > leaking out into the transport environment, which means something is
> > misconfigured, and all bets are off.
> >
> > In any case, it is not a transport conversion anticipated by the section
> > you're quoting, so I've no idea why a DKIM signer might opt to handle it
> > specially.
>
> I’m not as definite that this is a misconfiguration, but might be a 
> historical artifact. When we were editing RFC 4871, I remember discussing 
> with Eric Allman the problem with “from” at the beginning of a line. At the 
> time, we recognized that some messages would fail to verify because the 
> message would be modified in transit to add the >. IIRC this was particularly 
> a problem because message signing was done in a milter that operated on the 
> incoming leg of the message path (through sendmail, for example), when 
> ideally you would want signing to be done on the way out of the MTA.
>
> Your description of why the > was added is probably correct, but I think 
> there are circumstances where the > leaks out that aren’t just due to 
> misconfiguration. I have two messages in my bloated inbox that apparently 
> have had > added (many of you may have the “Communications of the ACM, May 
> 2023” message from April 24). They pass dkim verification, probably because 
> they were signed after modification.
>
> -Jim
>
> ___
> 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] DMARC2 & SPF Dependency Removal

[Hector Santos]

> 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 in that format, "From " at the front
>> of a line has a specific meaning (i.e., "this is a new message").  If that
>> insertion is happening in transport, then a local mailbox convention is
>> leaking out into the transport environment, which means something is
>> misconfigured, and all bets are off.
>> 
>> In any case, it is not a transport conversion anticipated by the section
>> you're quoting, so I've no idea why a DKIM signer might opt to handle it
>> specially.
> 
> I’m not as definite that this is a misconfiguration, but might be a 
> historical artifact.

Very historic - UUCP days and it didn’t come with the “>” prefix. Thats 
something new to perhaps mask and avoid stripping at the MDA.




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

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

[Jim Fenton]

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 meaning (i.e., "this is a new message").  If that
> insertion is happening in transport, then a local mailbox convention is
> leaking out into the transport environment, which means something is
> misconfigured, and all bets are off.
>
> In any case, it is not a transport conversion anticipated by the section
> you're quoting, so I've no idea why a DKIM signer might opt to handle it
> specially.

I’m not as definite that this is a misconfiguration, but might be a historical 
artifact. When we were editing RFC 4871, I remember discussing with Eric Allman 
the problem with “from” at the beginning of a line. At the time, we recognized 
that some messages would fail to verify because the message would be modified 
in transit to add the >. IIRC this was particularly a problem because message 
signing was done in a milter that operated on the incoming leg of the message 
path (through sendmail, for example), when ideally you would want signing to be 
done on the way out of the MTA.

Your description of why the > was added is probably correct, but I think there 
are circumstances where the > leaks out that aren’t just due to 
misconfiguration. I have two messages in my bloated inbox that apparently have 
had > added (many of you may have the “Communications of the ACM, May 2023” 
message from April 24). They pass dkim verification, probably because they were 
signed after modification.

-Jim

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

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

[Richard Clayton]

-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 prescribed limit of 10 was determined to cause too many SPF
passes not to be found...

> given 
>that we replaced local PSL lookups with a series of queries.  We cannot do 
>that 
>and pretend that SPF is too expensive.

the change here is not, I believe, 15 ... or even 10  (I think, counting
quickly on my fingers, it's +3 -- and for the vast majority of cases +0)

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZIUeV92nQQHFxEViEQLzKgCfRotct0/P4e2sKJm0bGi/biVBF5gAnioH
e8rlOpyGxUI3Y6+a4nQfCspM
=nexz
-END PGP SIGNATURE-

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

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

[Jesse Thompson]

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 inbound logs, 
nor DMARC reports for customer domains, so our awareness of this issue is 
dependent on being told.

That said, at MAAWG we were made aware of an edge case which is resulting in 
DKIM failures. Presumably, unknown bugs like this are inflating the numbers to 
support the "pro keeping SPF in DMARC" argument.

I typically advise customers that DKIM (CNAMEs with managed rotation) is 
enough. But that's speaking as a sender that supports DKIM. I suppose that some 
senders still aren't willing to implement DKIM today.

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

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

[Alessandro Vesely]

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 right 
now, featuring large an small companies.  Surely they must be misconfigured...


Two names are twitter.com and gnupg.org.  The latter cannot be said to be 
crypto-ignorant.



Best
Ale
--





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

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

[Murray S. Kucherawy]

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 Conversions, gives
> different advice.  UTF-8, though, seems to be subject to mutating
> fashions;
> conversion to 7-bit form, IMHO, makes sense only if it is base64.  Quoted
> printable is messy and prevents recovery after MLM transformation.
>

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 meaning (i.e., "this is a new message").  If that
insertion is happening in transport, then a local mailbox convention is
leaking out into the transport environment, which means something is
misconfigured, and all bets are off.

In any case, it is not a transport conversion anticipated by the section
you're quoting, so I've no idea why a DKIM signer might opt to handle it
specially.

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

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

[Barry Leiba]

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 can also choose to change the
version number (or not).

We're discussing (2).  We will not discuss (1) at all, in any way.

Barry

On Fri, Jun 9, 2023 at 8:55 PM Hector Santos
 wrote:
>
> 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 you wishing this now?
>
> Hector
>
>
> > On Jun 9, 2023, at 8:27 PM, Barry Leiba  wrote:
> >
> > 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:
> >>
> >>> 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
> >>> SPF outside of DMARC, and any discussion of that is *out of scope* for
> >>> this working group under its current charter.
> >>>
> >>> Barry, as chair
> >>
> >> For the record,  from a long time SMTP implementer standpoint, DMARC would 
> >> be ignored, dropped, turned off, etc first before any consideration to 
> >> stop SPF support.   As a Transporter, SPF works. As an Administrator - 
> >> ADSP, I mean “Supper ADSP” aka DMARC has been horrible.  I, and most 
> >> people, could easily deprecate Wildcat! DMARC with no harm and fact, less 
> >> harm because the false positives will disappear.  My product add-on for 
> >> wcSMTP, wcDMARC, never did honor the p=reject|quarantine. It was left for 
> >> filters and no one hard any confidence to make it work.
> >>
> >> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if 
> >> it’s about sparate, but not abandon, that I can support - because it is 
> >> already separate.  SPF preempts DMARC or any Payload protocol..
> >>
> >> Thanks
> >>
> >
> > ___
> > 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] DMARC2 & SPF Dependency Removal

[Hector Santos]

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 you wishing this now?

Hector


> On Jun 9, 2023, at 8:27 PM, Barry Leiba  wrote:
> 
> 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:
>> 
>>> 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
>>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>>> this working group under its current charter.
>>> 
>>> Barry, as chair
>> 
>> For the record,  from a long time SMTP implementer standpoint, DMARC would 
>> be ignored, dropped, turned off, etc first before any consideration to stop 
>> SPF support.   As a Transporter, SPF works. As an Administrator - ADSP, I 
>> mean “Supper ADSP” aka DMARC has been horrible.  I, and most people, could 
>> easily deprecate Wildcat! DMARC with no harm and fact, less harm because the 
>> false positives will disappear.  My product add-on for wcSMTP, wcDMARC, 
>> never did honor the p=reject|quarantine. It was left for filters and no one 
>> hard any confidence to make it work.
>> 
>> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
>> about sparate, but not abandon, that I can support - because it is already 
>> separate.  SPF preempts DMARC or any Payload protocol..
>> 
>> Thanks
>> 
> 
> ___
> 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] DMARC2 & SPF Dependency Removal

[Barry Leiba]

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:
>
> > 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
> > SPF outside of DMARC, and any discussion of that is *out of scope* for
> > this working group under its current charter.
> >
> > Barry, as chair
>
> For the record,  from a long time SMTP implementer standpoint, DMARC would be 
> ignored, dropped, turned off, etc first before any consideration to stop SPF 
> support.   As a Transporter, SPF works. As an Administrator - ADSP, I mean 
> “Supper ADSP” aka DMARC has been horrible.  I, and most people, could easily 
> deprecate Wildcat! DMARC with no harm and fact, less harm because the false 
> positives will disappear.  My product add-on for wcSMTP, wcDMARC, never did 
> honor the p=reject|quarantine. It was left for filters and no one hard any 
> confidence to make it work.
>
> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
> about sparate, but not abandon, that I can support - because it is already 
> separate.  SPF preempts DMARC or any Payload protocol..
>
> Thanks
>

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

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

[Hector Santos]

> 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
> SPF outside of DMARC, and any discussion of that is *out of scope* for
> this working group under its current charter.
> 
> Barry, as chair

For the record,  from a long time SMTP implementer standpoint, DMARC would be 
ignored, dropped, turned off, etc first before any consideration to stop SPF 
support.   As a Transporter, SPF works. As an Administrator - ADSP, I mean 
“Supper ADSP” aka DMARC has been horrible.  I, and most people, could easily 
deprecate Wildcat! DMARC with no harm and fact, less harm because the false 
positives will disappear.  My product add-on for wcSMTP, wcDMARC, never did 
honor the p=reject|quarantine. It was left for filters and no one hard any 
confidence to make it work.

SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
about sparate, but not abandon, that I can support - because it is already 
separate.  SPF preempts DMARC or any Payload protocol..

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

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

[Barry Leiba]

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 rate, while SPF would not (for direct
> connections
...
> The leads to a situation where the DMARC pass rate for direct connections
> would vary depending on if SPF was included:
>
> DKIM only: ~99.5%
> DKIM + SPF: ~100%
> SPF only: ~100%

That's interesting and disturbing if it remains consistent.
Theoretically, DKIM should *never* fail when SPF succeeds, so if
that's happening it means there is:
1. bad signing software,
2. bad verifying software,
3. misconfiguration somewhere,
...or a combination of those three.

I would *really* like to see a current study of this, because I think
it's critical for the future viability of DMARC, whether or not we
accept the proposal to remove SPF.  If DKIM is not working reliably
when it should, we absolutely need to understand why and work on
getting it fixed if we can.  If there used to be problems that do not
currently exist, we need to understand that as well, so we can make
current arguments with currently accurate data.  Either way, we need
to know what's really happening.

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?

Thanks again, Scott,
Barry

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

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

[Alessandro Vesely]

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 mutating fashions; 
conversion to 7-bit form, IMHO, makes sense only if it is base64.  Quoted 
printable is messy and prevents recovery after MLM transformation.



Best
Ale
--





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

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

[Alessandro Vesely]

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 the spec, so one cannot say a signer is defective if it doesn't
do it.


Have you seen that happen in the MTA relay process (in transit), or
only after final delivery?  I can see that an MDA or a recipient MUA
might do that, but it should *not* happen in transit, so it shouldn't
affect DMARC processing.  Do you have actual examples where an MTA is
making that change and breaking the DKIM sig?



I recall it was a problem, which is why I coded the replacement (I add a space, 
not a '>').  In the early years, DKIM suffered mime-autoconversions that many 
MTA were applying just for fun.  And there were some other corner cases that 
now defeat my recollection.


Anyway, having a second string at one's bow is not a defect, unless it's set up 
in a defective way.  But also DKIM can be misconfigured, which is not a good 
reason to eliminate it.  Having both increases the chances of success.



Best
Ale
--




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

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

[Scott Kitterman]

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:
> > Software engineering isn't a perfect science.  In general, a more
> > complex protocol will suffer more defects.  If you want to design
> > things that only work when software is perfect, I'm not interested.
> 
> It seems that you're saying you're "not interested" in any protocol
> that won't work if there's a software bug, and that makes no sense to
> me.  Crypto is hard to get right and there are often bugs; TLS won't
> work if you don't get the crypto right: does that mean you're not
> interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
> because it will fail if there's a bug in the network stack?  For that
> matter, a router with a bug in its MPLS implementation won't work:
> should we not use MPLS?  And, well, if there's a bug in your
> SPF-record parser, SPF won't work either, n'est-ce pas?
> 
> Of course, the level of failure in any of this depends upon just what
> the bug is.

Thanks for pushing back on this.  It was poorly worded.  Let me try again, see 
below.

> > One could make the opposite argument too, and I think it would be
> > equally valid:
> > 
> > The only value DKIM brings for DMARC is for indirect mail flows.  For
> > any direct connections, SPF is sufficient.  All the proposed DKIM
> > changes to solve the DKIM replay problem are likely to break indirect
> > mail flows anyway, so there's no longer a point to keep DKIM.  It's
> > much more complicated and it looks like the benefit of it is going
> > away, let's just simplify the protocol and get rid of it.
> 
> This also makes no sense, as it completely misrepresents the situation
> I'm raising.  It *doesn't* work both ways, because DKIM works in all
> situations that SPF does, but it *also* works in some situations where
> SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
> does.  SPF does not add value, ever.
> 
> You and Mike seem to be holding on to SPF because you want to, with
> some vague "I've seen network errors and software errors" statements
> but without real arguments.  The only real argument I've seen is
> Seth's about broader deployment of SPF without DKIM.  I've already
> said why I think that's not a reason we should keep SPF, but at least
> that is a reason I can make sense of.

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 rate, while SPF would not (for direct 
connections - I have no disagreement with your statement that SPF doesn't help 
with indirect mail flows).  This probably exculpates DNS as a source of the 
DKIM failures, since I think it's not likely that SPF records could be 
retrieved when DKIM key records could not, but I don't know for sure.

The leads to a situation where the DMARC pass rate for direct connections 
would vary depending on if SPF was included:

DKIM only: ~99.5%
DKIM + SPF: ~100%
SPF only: ~100%

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.

The point I was attempting (badly) to make is that I have seen data that's 
contrary to your claim that there is no case where SPF will enable a DMARC 
pass that DKIM would not also yield a DMARC pass, so we don't need it.  My 
judgement is that you are assuming too much perfection out of DKIM and the 
data doesn't support it.

Does that make more sense?

Scott K




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

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

[Murray S. Kucherawy]

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
> > that's not in the spec, so one cannot say a signer is defective if it
> doesn't
> > do it.
>
> Have you seen that happen in the MTA relay process (in transit), or
> only after final delivery?  I can see that an MDA or a recipient MUA
> might do that, but it should *not* happen in transit, so it shouldn't
> affect DMARC processing.  Do you have actual examples where an MTA is
> making that change and breaking the DKIM sig?
>

My impression is that this translation (from "From " to ">From " and back)
is only supposed to happen at the endpoints.  If done properly, the
signature would be generated after the translation on egress and verified
prior to the translation on ingress.  DKIM is supposed to be executed
against the content that will be "on the wire".  If it's being done in
flight, something is broken.

And signing software shouldn't be mutating messages ever (other than adding
signatures, of course).

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

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

[Barry Leiba]

> 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 if it doesn't
> do it.

Have you seen that happen in the MTA relay process (in transit), or
only after final delivery?  I can see that an MDA or a recipient MUA
might do that, but it should *not* happen in transit, so it shouldn't
affect DMARC processing.  Do you have actual examples where an MTA is
making that change and breaking the DKIM sig?

I would be surprised, but, well, I've been surprised many times by
what email software will do.

> What I find nonsensical is to eliminate SPF in order to save DNS queries, 
> given
> that we replaced local PSL lookups with a series of queries.  We cannot do 
> that
> and pretend that SPF is too expensive.

Yes, I agree: the DNS query load is not one of the arguments I'm making.

Barry

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

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

[Alessandro Vesely]

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.



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.



I agree SPF is too much bloated by some providers, to the point that 
impersonation with dmarc=pass can be achieved programmatically.  However, I'd 
rather counter this using an extra spf=no tag, than v=DMARC2.  (Furthermore, 
I'd specify such extra tag in a separate document, not dmarcbis.)


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 if it doesn't 
do it.


What I find nonsensical is to eliminate SPF in order to save DNS queries, given 
that we replaced local PSL lookups with a series of queries.  We cannot do that 
and pretend that SPF is too expensive.



Best
Ale
--





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

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

[Barry Leiba]

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 its current charter.

Barry, as chair

On Fri, Jun 9, 2023 at 9:39 AM Barry Leiba  wrote:
>
> Thanks for some data, Doug.  One comment on what's after the data
> (still talking as a participant here):
>
> > We have two topics intermixed:  (a) should we deprecate SPF for DMARC 
> > purposes, and (b) should we
> > deprecate SPF completely.   We should definitely not deprecate SPF 
> > completely.
>
> I am certainly not intermixing these!  I agree with you that we should
> *not* deprecate SPF at this time.  I am *only* supporting that we
> remove its use in the standards-track version of DMARC, and that's all
> this working group has scope to do anyway, according to our charter.
> And, yes, a recipient that uses DMARC with DKIM only... is quite free
> to *also* consider SPF in its decision about handling the message...
> just (if we do this) not as part of the DMARC evaluation.
>
> Barry

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

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

[Barry Leiba]

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
> complex protocol will suffer more defects.  If you want to design
> things that only work when software is perfect, I'm not interested.

It seems that you're saying you're "not interested" in any protocol
that won't work if there's a software bug, and that makes no sense to
me.  Crypto is hard to get right and there are often bugs; TLS won't
work if you don't get the crypto right: does that mean you're not
interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
because it will fail if there's a bug in the network stack?  For that
matter, a router with a bug in its MPLS implementation won't work:
should we not use MPLS?  And, well, if there's a bug in your
SPF-record parser, SPF won't work either, n'est-ce pas?

Of course, the level of failure in any of this depends upon just what
the bug is.

> One could make the opposite argument too, and I think it would be
> equally valid:
>
> The only value DKIM brings for DMARC is for indirect mail flows.  For
> any direct connections, SPF is sufficient.  All the proposed DKIM
> changes to solve the DKIM replay problem are likely to break indirect
> mail flows anyway, so there's no longer a point to keep DKIM.  It's
> much more complicated and it looks like the benefit of it is going
> away, let's just simplify the protocol and get rid of it.

This also makes no sense, as it completely misrepresents the situation
I'm raising.  It *doesn't* work both ways, because DKIM works in all
situations that SPF does, but it *also* works in some situations where
SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
does.  SPF does not add value, ever.

You and Mike seem to be holding on to SPF because you want to, with
some vague "I've seen network errors and software errors" statements
but without real arguments.  The only real argument I've seen is
Seth's about broader deployment of SPF without DKIM.  I've already
said why I think that's not a reason we should keep SPF, but at least
that is a reason I can make sense of.

Barry

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

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

[Douglas Foster]

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 this
data is not limited to policy-publishing domains

Successful Verification Rates based on verification method
-
DKIM & SPF : 54.6%
DKIM-only: 14.5%
SubTotal : 69.1% have DKIM-verified FROM addresses.  This is consistent
with Tobias's data

SPF-aligned: 14.5%   This is much higher than what Tobias reported, but his
data probably includes a mix of spam and non-spam
SubTotal : 83.6%  (Messages with a verified FROM address using SPF and DKIM
together)

SPF-local:  8.5% (SPF Pass but not aligned, yet FROM is trusted using local
policy)
Total  92.1% of all messages have a FROM address that  I consider
acceptably verified.

I had an experience where dual-authentication was useful.  A software
update caused my MTA to "forget" its DKIM configuration.The fix
required generating a new key pair, publishing the public key, and hoping
that DNS propagated quickly to those who needed it.I was glad for
SPF-aligned authentication during the interim between when the problem was
introduced and the fix was propagated.

We have two topics intermixed:  (a) should we deprecate SPF for DMARC
purposes, and (b) should we deprecate SPF completely.   We should
definitely not deprecate SPF completely.In my experience, filtering
software collects all of its data before making any decisions, rather than
interleaving the data collection process with the filtering process for the
purpose of minimizing data collection effort.   DMARC reporting and ARC
Sets seem to depend on filters behaving in this way.  So, even if DMARC
drops SPF, I don't think there will be a measurable benefit to DNS
workload, because SPF is useful for other purposes.

I do think readers would benefit from a frank discussion about the SPF
risks associated with shared tenancy and excessive inclusion.   They should
understand that removing SPF policies, and depending on DMARC alone, can be
a successful way to manage those risks.

Doug Foster


On Thu, Jun 8, 2023 at 10:21 AM 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
>> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

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 matter, but in 
practice it is.

Software engineering isn't a perfect science.  In general, a more complex 
protocol will suffer more defects.  If you want to design things that only work 
when software is perfect, I'm not interested.

In terms of utility for direct connections, I think having both helps and I 
don't find claims the SPF can never pass when DKIM fails to be credible.  If 
someone has data that shows that's true now, I'd be interested to see it (my 
experience is a few years ago, so things may have changed).

Ultimately, I think SPF and DKIM both suffer from what I'll genetically call 
data hygiene problems.  SPF is mostly adding third party providers who are 
insufficiently careful (might not even care, I don't know) generating SPF pass 
results for "bad" mail.  DKIM is mostly about replay attacks.  Neither of these 
are protocol problems and I don't think support dumping one or the other out of 
DMARC.

One could make the opposite argument too, and I think it would be equally valid:

The only value DKIM brings for DMARC is for indirect mail flows.  For any 
direct connections, SPF is sufficient.  All the proposed DKIM changes to solve 
the DKIM replay problem are likely to break indirect mail flows anyway, so 
there's no longer a point to keep DKIM.  It's much more complicated and it 
looks like the benefit of it is going away, let's just simplify the protocol 
and get rid of it.

Now, I think that's a bad argument, but I don't think it's any worse than the 
argument being presented to get rid of SPF.

Scott K

On June 8, 2023 10:26:59 PM UTC, Barry Leiba  wrote:
>> 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 failures.
>
>Oh, well, I don't buy this one at all: My software might have bugs, so
>I have to use multiple mechanisms?  No, you have to fix the software.
>"Software might have bugs" is not a reason to put extra complexity
>into a protocol.
>
>Would you suggest including two DKIM signatures using different crypto
>suites in order to work around possible software bugs?  Would you
>suggest putting that into the protocol definition?
>
>> It's true that SPF is not particularly helpful for indirect mail flows, but 
>> I read your message as claiming
>> using SPF with DKIM causes DMARC verification to be worse for indirect mail 
>> flows than when using
>> DKIM alone.  Is that right?
>
>What I said was that there is no case where DKIM will fail and SPF
>will succeed.  I stand by that statement.  Can you describe a scenario
>that breaks DKIM but has SPF still work?
>
>That's assuming the software is working right and one hasn't
>configured it wrong, both of which should be fixed.  And if you can't
>retrieve a needed DNS record, you need to wait and retry, not try to
>put unnecessary redundancy into the protocol.  Unless, of course, you
>can show that DKIM is significantly more likely to fail for that
>reason than SPF is.
>
>The other thing I said about SPF is that there are cases now where the
>SPF records required by the use of major service providers are so
>bloated and contain so many IP addresses that they allow spammers who
>use those same services to spoof any other customer of the service.
>That makes SPF validation weak.  As there's no benefit to it over
>DKIM, I don't understand why we'd want to keep it.
>
>We needed SPF when DKIM was less widely deployed.  We thought it was
>more useful when we hadn't seen how often it breaks compared with
>DKIM.  And one advantage that SPF had -- that it allowed you to reject
>a message during the SMTP negotiation, before the DATA command was
>accepted -- can't be used if you need to check DKIM as well.
>
>Barry
>
>___
>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] DMARC2 & SPF Dependency Removal

[Barry Leiba]

> 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 failures.

Oh, well, I don't buy this one at all: My software might have bugs, so
I have to use multiple mechanisms?  No, you have to fix the software.
"Software might have bugs" is not a reason to put extra complexity
into a protocol.

Would you suggest including two DKIM signatures using different crypto
suites in order to work around possible software bugs?  Would you
suggest putting that into the protocol definition?

> It's true that SPF is not particularly helpful for indirect mail flows, but I 
> read your message as claiming
> using SPF with DKIM causes DMARC verification to be worse for indirect mail 
> flows than when using
> DKIM alone.  Is that right?

What I said was that there is no case where DKIM will fail and SPF
will succeed.  I stand by that statement.  Can you describe a scenario
that breaks DKIM but has SPF still work?

That's assuming the software is working right and one hasn't
configured it wrong, both of which should be fixed.  And if you can't
retrieve a needed DNS record, you need to wait and retry, not try to
put unnecessary redundancy into the protocol.  Unless, of course, you
can show that DKIM is significantly more likely to fail for that
reason than SPF is.

The other thing I said about SPF is that there are cases now where the
SPF records required by the use of major service providers are so
bloated and contain so many IP addresses that they allow spammers who
use those same services to spoof any other customer of the service.
That makes SPF validation weak.  As there's no benefit to it over
DKIM, I don't understand why we'd want to keep it.

We needed SPF when DKIM was less widely deployed.  We thought it was
more useful when we hadn't seen how often it breaks compared with
DKIM.  And one advantage that SPF had -- that it allowed you to reject
a message during the SMTP negotiation, before the DATA command was
accepted -- can't be used if you need to check DKIM as well.

Barry

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

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

[Scott Kitterman]

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 makes sense: if there's a transient DNS failure,
>then neither the SPF nor the DKIM (nor the DMARC) records can be
>retrieved.
>
>I also don't see how using an unreliable mechanism is a benefit.  It
>demonstrably hurts validation rates related to relayed/forwarded mail,
>and can cause *false* validations in cases of overly-broad SPF
>configurations (as when a large provider that also hosts many spammers
>is used).

I'm pretty sure he meant SPF and DKIM.  His statement is consistent with my 
observations.

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 failures.  

It's true that SPF is not particularly helpful for indirect mail flows, but I 
read your message as claiming using SPF with DKIM causes DMARC verification to 
be worse for indirect mail flows than when using DKIM alone.  Is that right?  
If so, please expand on that because I don't understand it.

Scott K

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

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

[Dotzero]

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 while in the middle of something else. Proof that one
should always proof read before hitting send.

>
> I don't see how that makes sense: if there's a transient DNS failure,
> then neither the SPF nor the DKIM (nor the DMARC) records can be
> retrieved.
>

One example is where there are a pool of DNS servers. One server in a pool
might have an issue while others are fine. All the lookups do not
necessarily hit the same server. You also don't factor in cached results
for SPF as well as potentially different TTLs for those results.

>
> I also don't see how using an unreliable mechanism is a benefit.  It
> demonstrably hurts validation rates related to relayed/forwarded mail,
> and can cause *false* validations in cases of overly-broad SPF
> configurations (as when a large provider that also hosts many spammers
> is used).
>

It's all in the mail flow and configurations. YMMV. I was dealing almost
overwhelmingly with transactional emails in a well configured environment
(from the day that DMARC was originally published we were at p=reject)).
Yes, we had to fix some things beforehand. I strongly believe that the 2
biggest problems with setting up email authentication as a sender is that
people don't put much thought into it and in many cases they deploy when
their hair is on fire.

Michael Hammer

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

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

[Barry Leiba]

> 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 the SPF nor the DKIM (nor the DMARC) records can be
retrieved.

I also don't see how using an unreliable mechanism is a benefit.  It
demonstrably hurts validation rates related to relayed/forwarded mail,
and can cause *false* validations in cases of overly-broad SPF
configurations (as when a large provider that also hosts many spammers
is used).

Barry

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

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

[Dotzero]

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 DMARC validation.


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

I'm going to disagree with you on this, having experience with billions of
emails sent with both SPF and DKIM used in the context of DMARC validation.
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. A small percentage of a very large number is still a large
number. Let's not throw the baby out with the bath water.

>
> Barry, as participant
>

Michael Hammer


>
> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank  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 
>> 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
 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
>>>
>>
>>
>> --
>>
>> *Seth Blank * | Chief Technology Officer
>> *e:* s...@valimail.com
>> *p:* 415.273.8818
>>
>> 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
>>
> ___
> 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] DMARC2 & SPF Dependency Removal

[Hector Santos]

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



Thank you for inviting feedback on Mr. Herkula's interesting DMARC2 proposal, 
focusing on detaching SPF from DMARC's evaluation process. I would like to 
share my thoughts on this matter.

While the principle behind the proposed DMARC2 is valuable, I remain sceptical 
about the effectiveness of separating SPF from DMARC to alleviate DNS load. For 
various reasons, notably the layer issue – SPF being an SMTP protocol rather 
than a payload protocol – SPF is unlikely to be fully discarded.

It's worth recalling that SPF's contribution has served the email community 
well, despite certain node transition issues such as relays and forwards. The 
optional integration of SPF within DMARC1 from the onset might have simplified 
the process, mitigating the challenges associated with the merged results and 
reducing the occurrence of false positives, which in many cases has begun to 
give domains a second thought on using p=reject|quarantine policies. 

A potential DMARC2 proposal should, in my opinion, maintain backward 
compatibility, making SPF an optional requirement.  The real gap with DMARC1 
has been the lack of diversity in policies, and effectively, the DMARC2 
proposal could add a new "policy" that doesn't require SPF evaluation.

For context, we've amassed nearly two decades worth of data on SPF, DKIM, ADSP, 
and DMARC, providing considerable insight into the longevity and effectiveness 
of these measures.

It's crucial to establish that SPF was deliberately designed to, and in many 
cases will, use a HARDFAIL result to preempt payload transfer or its acceptance 
(at DATA). This is precisely why the SUBMITTER add-on ESMTP protocol was 
introduced as part of SenderID – the payload version of SPF – to relay the 
Purported Responsible Address (PRA) at the SMTP MAIL FROM command.

By reviving the SUBMITTER protocol for DMARC purposes, servers/receivers can 
check the DMARC policy at SMTP, offering valuable foresight into the email 
domain's expectations prior to payload delivery. This approach allows for a 
more optimized process, ensuring that SPF is evaluated at MAIL FROM or RCPT TO, 
once the recipient address's acceptability is established per RFC 5321, Section 
3.3 Mail Transactions' recommendations.

It's important to note that SPF-compliant servers – as evidenced recently by 
gmail.com – can reject SPF failures at SMTP independent of DMARC. For domains 
using SPF hard failures (-ALL), DMARC is not mandatory and in many cases, a 
hard SPF policy vs hard  DMARC policies are mutual exclusive.  Odds are good, 
if SPF was disabled, DMARC2 could yield the same way. I suggest that the 
proposed DMARC2 revisit the coupling of SOFTFAIL SPF results with DMARC2 policy 
analysis.  

While DMARC has introduced complexities and some uncertainty, my recent 
analysis reveals that domains without DMARC, but implementing hard SPF 
policies, experienced minimal issues, except for gmail.com domain members. The 
problem appears to be more prominent with ESPs, particularly those with a 
lenient DMARC p=nonen since ESPs with strong policies are restricted from 
subscriptions and submissions.

In conclusion, the evolution to a DMARC2 should focus on addressing these 
concerns, potentially including a "rewrite=1" option to mailing lists with 
appropriate permissions. This could potentially make it more palatable to 
modify the author's address, while respecting the hard-won email security 
principles.

Thanks

---
Hector Santos
Santronics Software,Inc.












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

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

[Hector Santos]

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  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  > 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 > > 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 
>>> 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 >>> > wrote:
> 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%) 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 

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

[Benny Pedersen]

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 list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Barry Leiba]

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 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  40valimail@dmarc.ietf.org> 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 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 when we’ve been so good at simplifying DMARC
> >through the bis process and removing flags, but what about a way to say “I
> >only send with DKIM, and do not evaluate SPF on my behalf”?
> >
> >That wouldn’t create an interop problem, and gives a path to upgrade
> >without creating breaking change out of the gate?
> >
> >Seth
> >
> >On Thu, Jun 8, 2023 at 16:05 Barry Leiba  wrote:
> >
> >> 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
> >> different information now, and we need to say that of you want to
> reliably
> >> authenticate you have to use DKIM… that’s it.
> >>
> >> Barry
> >>
> >> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
> >>> 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   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>
> > 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
> >>> insights drawn are quite enlightening. Of these, 2.2 billion emails
> >>> (approximately 69%) passed the DMARC check successfully. It's
> quite 

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

[Seth Blank]

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 SPF more problematic.

I’m in general agreement with you that SPF and DKIM work in concert, and
you can’t just look at them in isolation. Even small percentages in email
represent billions of messages, as we all know from mailing list damage
from DMARC being “less than a percent.”

On Thu, Jun 8, 2023 at 16:51 Scott Kitterman  wrote:

> 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  40valimail@dmarc.ietf.org> 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 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 when we’ve been so good at simplifying DMARC
> >through the bis process and removing flags, but what about a way to say “I
> >only send with DKIM, and do not evaluate SPF on my behalf”?
> >
> >That wouldn’t create an interop problem, and gives a path to upgrade
> >without creating breaking change out of the gate?
> >
> >Seth
> >
> >On Thu, Jun 8, 2023 at 16:05 Barry Leiba  wrote:
> >
> >> 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
> >> different information now, and we need to say that of you want to
> reliably
> >> authenticate you have to use DKIM… that’s it.
> >>
> >> Barry
> >>
> >> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
> >>> 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   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>
> > wrote:
> >
> >> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula  >> 

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

[Scott Kitterman]

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 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 when we’ve been so good at simplifying DMARC
>through the bis process and removing flags, but what about a way to say “I
>only send with DKIM, and do not evaluate SPF on my behalf”?
>
>That wouldn’t create an interop problem, and gives a path to upgrade
>without creating breaking change out of the gate?
>
>Seth
>
>On Thu, Jun 8, 2023 at 16:05 Barry Leiba  wrote:
>
>> 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
>> different information now, and we need to say that of you want to reliably
>> authenticate you have to use DKIM… that’s it.
>>
>> Barry
>>
>> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
>>> 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 >>> 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 
> 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
>>> 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.

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

[Scott Kitterman]

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
>> 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?
>
I don't have data, but I do have a different view on how to frame the data.

We've expended a lot of cycles in this working group on trying to figure out 
how to make DMARC more reliable because it is not sufficiently so for all 
domains to publish a restrictive DMARC policy (in fact, progress in the working 
group is currently blocked on the question of how to describe this).

I don't think DMARC has a surplus of reliability such that we should think 
about giving some of it away voluntarily.  I submit that this 1.6% is not 
"mere", it's huge.

What do I mean by that?  That 1.6% will include both domains which use SPF 
alone and which use both SPF and DKIM.  DKIM is not perfect.  When I did have 
access to relevant data, I recall seeing typical DKIM verification rates for 
direct mail typically between 99.2% and 99.8%.  It was never 100%.  For SPF, 
when the SPF record was correct, it was almost always 100%.  Based on this 
historical experience, I suspect that a significant fraction of that 1.6% are 
cases like this where SPF saves the DMARC result when DKIM has failed.  

For the overall protocol, DKIM and SPF are complementary.  While an estimated 
0.5% drop in DMARC failures may not seem like much, I think it's a lot and we 
don't have a surfeit of reliability that we should give some away.

I suspect that the real driver here is senders allowing too much "bad" mail to 
get an SPF pass (I have also seen, but do not have access to, data that 
indicates this is the case).  DKIM has similar problems (see the recent DKIM 
working group discussions on replay attacks).  I think working on that problem 
(SPF/DKIM pass rates for "bad" mail) is where the focus should be.

Not a DMARC working group issue.

Scott K

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

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

[Tobias Herkula]

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 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 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 when we’ve been so good at simplifying DMARC through 
the bis process and removing flags, but what about a way to say “I only send 
with DKIM, and do not evaluate SPF on my behalf”?

That wouldn’t create an interop problem, and gives a path to upgrade without 
creating breaking change out of the gate?

Seth

On Thu, Jun 8, 2023 at 16:05 Barry Leiba 
mailto:barryle...@computer.org>> wrote:
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 different information 
now, and we need to say that of you want to reliably authenticate you have to 
use DKIM… that’s it.

Barry

On Thu, Jun 8, 2023 at 3:54 PM Seth Blank 
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 
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 
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 
mailto:superu...@gmail.com>> 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 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 remark

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

[Seth Blank]

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 when we’ve been so good at simplifying DMARC
through the bis process and removing flags, but what about a way to say “I
only send with DKIM, and do not evaluate SPF on my behalf”?

That wouldn’t create an interop problem, and gives a path to upgrade
without creating breaking change out of the gate?

Seth

On Thu, Jun 8, 2023 at 16:05 Barry Leiba  wrote:

> 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
> different information now, and we need to say that of you want to reliably
> authenticate you have to use DKIM… that’s it.
>
> Barry
>
> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
>> 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 >> 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 
 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
>> 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 
>> 

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

[Barry Leiba]

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
different information now, and we need to say that of you want to reliably
authenticate you have to use DKIM… that’s it.

Barry

On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
> 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 > 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 
>>> 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
> 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

>>>
>>>
>>> --
>>>
>>> *Seth Blank * | Chief Technology Officer
>>> *e:* s...@valimail.com
>>> *p:* 415.273.8818
>>>
>>> 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, 

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

[Barry Leiba]

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

>>>
>>>
>>> --
>>>
>>> *Seth Blank * | Chief Technology Officer
>>> *e:* s...@valimail.com
>>> *p:* 415.273.8818
>>>
>>> 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

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

[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 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  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  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 
>> 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
 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
>>>
>>
>>
>> --
>>
>> *Seth Blank * | Chief Technology Officer
>> *e:* s...@valimail.com
>> *p:* 415.273.8818
>>
>> 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
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org

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

[Barry Leiba]

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  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 
> 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
>>> 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
>>
>
>
> --
>
> *Seth Blank * | Chief Technology Officer
> *e:* s...@valimail.com
> *p:* 415.273.8818
>
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Seth Blank]

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


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:* 415.273.8818

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

[Murray S. Kucherawy]

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%) 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

[dmarc-ietf] DMARC2 & SPF Dependency Removal

[Tobias Herkula]

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, and a more accurate reflection of 
the current email landscape.

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.

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 switch from the Public Suffix List (PSL) to the Tree-Walk 
algorithm.

By moving towards DMARC2, we not only update our standard to better reflect our 
present requirements, but we also make a clear commitment to the ongoing 
evolution and improvement of the protocol.

Best regards,

Tobias Herkula
Mail Security & Transfer
1&1 (GMX, Web.de, Mail.com, IONOS)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc