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 <jan=
[email protected]> 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 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: [email protected]
GPG Signature: https://keys.dusatko.org/E535B585.asc
GPG Encrypt: https://keys.dusatko.org/B76A1587.asc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
