Re: [dmarc-ietf] Fwd: Priming the Pump for Discussion - Ratchets

[Douglas Foster <[e-mail]>]

Barry's comment:

I don't agree with the characterization of the second group.  I would
say that we are partitioning messages into these two groups:
- Those for which we can confirm that they originated in the domain
they say they did.
- Those for which we can not confirm that.


When we use P=REJECT, we assert that anything which cannot be confirmed is
unacceptable.   That makes for two pretty disjoint groups.   If
Authentication is only to be used to validate a whitelisting decision, then
a one-sided test would be sufficient.   In practice, the primary use for
DMARCv1 is to block messages, and much of our discussion has been around
the unwanted disposition that this places on mailing lists.

DKIM treats an invalid signature as non-existent.   It also treats a DKIM
signature as fully optional.   DMARCv1 changes the rules to gather more
usable information from the message.    DMARCv1 with P=REJECT says that a
message which lacks authentication is unacceptable, and since any message
might be forwarded, it has effectively made DKIM non-optional..  So we have
already modified the interpretation of DKIM.

I have observed that IF the domain owner indicates that all messages
originate with DKIM signatures, then the presence of a signature is no
longer optional at the evaluation point.    As I have said previously, this
provides a valid basis for partitioning messages between verified,
ambiguous, and repudiated.   If you accept the premise that mailing list
messages should not always be repudiated, then nothing we have done up to
this point has provided a reliable way to repudiate.   I am saying that
this is a problem that we can fix.

Upward Compatibility


Yes, I have gone radical, and I am no longer willing to be limited by the
design limitations of DMARCv1.   While DMARCv1 was apparently a
great success for PayPal, I perceive it as a failure when implemented
generally:

·         DMARCv1 has a significant problem with mailing lists, and the
mailing list interest has been well represented in this group.   Until my
proposal, the mailing list problem remained poorly addressed, even with ARC.

·         DMARCv1 has poor implementation support.   I remember someone
presenting a statistic to this group that only 6% of DMARC policies are
enforceable (p=reject or quarantine).    If this is even close to correct,
after 10 years of DMARCv1, it suggests a significant failure to capture the
affection of domain owners.



·         DMARCv1 has poor product support.   Many lower-end email
filtering products do not implement DMARC at all, which is not terribly
surprising.   But several high-end solutions implement DMARC enforcement
within their filter for incoming mail, while implementing DMARC violations
within their secure webmail product for outbound mail.   In-between these
extremes are some products that implement DMARC without adequate exception
methods, so the first false positive will require the feature to be
disabled.



I am no longer prepared to put window dressing on DMARCv1.   We need
DMARCbis to have a better design.