The gap between what is being attempted and what is needed is a huge
personal disappointment.

The DMARC goal should be to block malicious impersonation without blocking
wanted messages, where "wanted" is in the eyes of the evaluator and his end
user.    That puts the onus on the evaluator.   RFC 7960 said that
evaluators need to be aware of problems, but gave no solutions.   DMARCbis
replaces the evaluator with a mindless automaton, repeating all the worst
mistakes of RFC 7489.

This is from a real-world conversation with a product support tech:
   Me:  I cannot use your DMARC implementation because it does not have an
exception mechanism.
   Him:   Why would you need exceptions?
I blame his ignorance, and his product's inadequacies, on RFC 7489, which
defined no exceptions.

RFC 7489 falsely divides the mail stream into four groups:

   - Authenticated / Pass,
   - Unauthenticated without Prejudice (None),
   - Unauthenticated with Prejudice (Quarantine/Reject), and
   - No Result.

In reality, there are only two possible states:  Authenticated and Not
Authenticated.

   - The Mailing List problem proves that the distinction between None and
   Reject is a fiction.  At best, Fail with Reject justifies a slightly higher
   risk weight for environments that depend on weighting.
   - "No Result" is an error in RFC 7489.    The PSL and default alignment
   rules allowed a result to be calculated on any domain.   An evaluator
   cannot excuse a decision to allow malware infestation by saying, "the
   domain owner did not give me permission to check for malicious
   impersonation."   "No Result" is another way of saying, "I did not do my
   job."
   - Any unauthenticated message is a potential impersonation.  It is the
   evaluator's job to figure out whether malicious impersonation actually
   occurred or not.

Authentication failure provides a starting point, not an end point.  The
risk of malicious impersonation applies to every unauthenticated message.

Correct evaluation fixes the mailing list problem and fixes a lot of other
false blocks, while blocking the malicious traffic that RFC 7489 leaves
unmolested.

We need a document that is targeted at evaluators, to help them make
correct disposition decisions for their organizations.   The current
document blames the charter as the reason that it does not even try.

Doug Foster


On Wed, Nov 22, 2023 at 5:58 PM Seth Blank <s...@sethblank.com> wrote:

> Is there a point to this thread, that affects the text in the DMARCbis
> document under charter criteria?
>
> Seth, as Chair
>
> -mobile
>
>
> On Wed, Nov 22, 2023 at 07:13 Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> RFC 7489 and DMARCbis are written as algorithms without exception
>> conditions.  That silence leads product developers and mail administrators
>> to conclude that the algorithm can be implemented without allowing for
>> exceptions.   Why would we expect a different result?
>>
>> Withheld information can deceive.
>>
>>
>>
>>
>> On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely <ves...@tana.it> wrote:
>>
>>> On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote:
>>> > I see that the DMARC marketing machine is hard at work. There was an
>>> item on NPR (National Public Radio) “All Things Considered” this afternoon
>>> heavily promoting DMARC:
>>> >
>>> >
>>> https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season
>>> >
>>> > I have strong feelings about this article that are off-topic for this
>>> mailing list.
>>>
>>>
>>> What is not off-topic is the consideration that such sentiment implies
>>> that a
>>> prohibitive statement would turn out to mean /MUST NOT use mailing
>>> lists/.
>>>
>>>
>>> Best
>>> Ale
>>> --
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to