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