Re: [dmarc-ietf] p=quarantine

[Dotzero <[e-mail]>]

On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster <
[e-mail]> wrote:

> Sorry about the confusion caused by my typing failures.
> What I meant:
> First party - From address aligns with SMTP address.  Can be validated
> with SPF or DKIM.
> Third party - From address and SMTP address are in different domains.  Can
> be validated with DKIM only.
> I am open to suggestions for better nomenclature.
>
> But what I am trying to figure out is under what circumstances a DMARC
> policy can be considered actionable.   Do I conclude that "p=quarantine"
> means "domain is still collecting data, so results are unpredictable"?   Or
> do I conclude that it means "Domain is fully deployed and failure to
> validate is a highly suspicious event?"
>

You are way overthinking this.

>
> Take the case of a SMTP-aligned message which does not have a DKIM
> signature.   If it is received directly, it is DMARC compliant.   If it is
> received indirectly, it is a presumed spoof.    It cannot be both valid and
> spoofed.
>

Rather than using the word "spoofed", think of it as simply "failed to
validate" if it was forwarded. Done.


>  Whether the message gets forwarded is not under the sender's control.
>  If I receive it directly it is presumed valid, but does it signal that the
> domain is still struggling to implement DMARC, so their policy should be
> ignored on future messages?   Or if I receive it indirectly, should I try
> to reverse engineer whether it was SPF-aligned before it was forwarded?
>

You appear to be venturing into an area that involves tea leaves and
crystal balls - way beyond anything a technical standard can address. An
organization publishing a p=quarantine record is making a request that
messages purporting to be from their domain be quarantined if they fail to
validate. It doesn't matter whether it was sent direct or was handled by an
intermediary. Even a certain (very small) percentage of emails sent
directly can fail for various reasons. Why is it so difficult to take
things at face value? If, as a validating receiver you have data that you
believe justifies exercising local policy then you have a choice to make.
It really is that simple.

>
> Since all messages need to be DKIM-signed to survive a possible forward,
> should SPF even be part of the DMARC criteria?
>

Yes, SPF should be a part of DMARC because even with direct mail there can
be problems with DKIM signing/signatures for various reasons. The
combination of SPF and DKIM signing provides a small but useful increase in
the percentage of mail that validates. This statement is based on my
experience of having been responsible for systems sending several billions
of emails with a p=reject policy.

>
> I am simply wondering if a DMARC policy has enough reliable information to
> be of any value, at least for any setting other than p=reject pct=100.
> This is intertwined with the ambiguity about what the sender means for any
> policy other than p=reject pct=100.   My opening post was an attempt to
> define milestones that should be associated with specific settings.   But
> maybe the only certainty is that the domain is collecting data and
> consequently spoof-prevention must be based on evidence other than the
> DMARC policy.
>

Again, "spoofing" is a convenient but inaccurate descriptor.  DMARC is a
tool intended to prevent direct domain abuse based on the RFC 5322 From
email address, nothing more and nothing less. Even if an email message
validates for DMARC, it could be a homoglyph or cousin domain email address
in the RFC 5322 field. Attempting to overlay the meaning of a published
policy with other semantics or trying to guess the underlying intentions is
a perilous path for a standards body. Other tools and techniques can and
should be applied to messages by Receivers in order to protect their users.

Michael Hammer