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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jun 18 06:00:04 2023

[John Levine]

   Count|  Bytes |  Who
++---
 40 ( 100%) | 791849 ( 100%) | Total
  5 (12.5%) |  97781 (12.3%) | Douglas Foster 

  5 (12.5%) |  42484 ( 5.4%) | Barry Leiba 
  5 (12.5%) |  26092 ( 3.3%) | Alessandro Vesely 
  4 (10.0%) | 205885 (26.0%) | Hector Santos 
  4 (10.0%) |  40612 ( 5.1%) | Tero Kivinen 
  3 ( 7.5%) |  21602 ( 2.7%) | Murray S. Kucherawy 
  2 ( 5.0%) | 240188 (30.3%) | Steve Siirila 
  2 ( 5.0%) |  10727 ( 1.4%) | Sebastiaan de Vos 
  2 ( 5.0%) |   8356 ( 1.1%) | John Levine 
  1 ( 2.5%) |  29130 ( 3.7%) | Ken Simpson 
  1 ( 2.5%) |  19020 ( 2.4%) | Emil Gustafsson 
  1 ( 2.5%) |  12186 ( 1.5%) | Seth Blank 
  1 ( 2.5%) |  10129 ( 1.3%) | Jan Dušátko 
  1 ( 2.5%) |   9628 ( 1.2%) | Michael Kliewe 
  1 ( 2.5%) |   6446 ( 0.8%) | Scott Kitterman 
  1 ( 2.5%) |   6031 ( 0.8%) | Jim Fenton 
  1 ( 2.5%) |   5552 ( 0.7%) | Richard Clayton 

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