Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Douglas Foster <[e-mail]>]

You can disagree about whether this wording is appropriate, but there
should be no disagreement about the scope problem.   We do not have a
protocol which can handle all situations, and much of our discussion is
caused by those who apply DMARC to situations where it does not work.

Lets define "legitimate mail" as used in my proposed text to mean "delivery
is desired by the intended recipient and the message contains nothing that
threatens the interest of the user, the interest of the user's network, or
the policies of the user's organization."   Perhaps this is too
restrictive, because it  excludes advertising which is harmless in its
intent but unwanted by the recipient.

What is clear is that by this definition, mailing list messages are
legitimate, and yet are incompatible with DMARC.  Similarly, messages which
are tagged with informational content by a spam filter and then forwarded
at the request of the primary recipient are also legitimate.  In both
cases, specific messages may be unwanted or hostile, but the class of
messages is wanted.

My exception language is still incomplete, because we have another class of
senders who ignore DMARC but are too important to block.    My list in that
category includes a U.S. government agency and two vendors of cloud-based
products for secure web relay.

We need to set appropriate expectations for product developers, email
gateway operators, and domain owners.    Otherwise we end up with wrong
assumptions which lead to products which mindlessly apply a disposition
without providing adequate exception mechanisms.

Address rewriting is NOT the optimal answer to the problem, because it
hides the forwarding operation without addressing the complications that
forwarding creates for correctly evaluating email reputation.

Email evaluation products need to handle all possible scenarios.  This
includes
- forwarded and not forwarded
- with and without SMTP rewrite
- with and without modification.
- with and without From rewrite
- with and without ARC sets
- whether the email header chain is accurately documented or fraudulently
fabricated.

The only way to handle all of these scenarios is for the email filter to
examine the entire chain of Received headers and other headers.   There is
no simple algorithm for performing this analysis.   There is an opportunity
for IETF to provide ways for legitimate MTAs to facilitate this process,
and ARC is a step in the right direction, but only a first step.

We may be able to promote DMARC adoption by overselling its capabilities,
but I do not see that as a good thing.

DF


On Sun, Jan 3, 2021 at 7:48 AM Douglas Foster <
[e-mail]> wrote:

> But we do not have a comprehensive protocol, so we need to set appropriate
> expectations.
>
> I will define "legitimate mail" as used in my proposed text to mean
> "delivery is desired by the intended recipient and the message contains
> nothing that threatens the interest of the user, the interest of the user's
> network, or the policies of the user's organization."
>
> Either mailing list messages, as a class are legitimate, or not -- and we
> have concluded that they are.   (Indvidual messages could be in either
> category.)    Messages that are tagged by a spam filter and then forwarded
> to the recipients alternate mailbox are also legitimate.  We need to set
> appropriate expectations for product developers, email gateway operators,
> and domain owners. My exception language is actually still incomplete,
> because we have the category of senders who ignore DMARC but are too
> important to block.    My list in that category includes a U.S. government
> agency and two vendors of cloud-based email filtering software.
>
> DMARC FAIL can at best provide a data point for a filtering algorithm, as
> was stated in my interchange with Todd.   Claiming more than that will only
> result in misuse of DMARC concepts.
>
> There are real security issues to consider with forwarded mail.   Address
> rewriting hides some of them without solving the problems.   We need an
> in-depth assessment of how to evaluate forwarded mail.   Is this group the
> one to do it or is it assigned somewhere else?
>
> Doug Foster
>
> On Sun, Jan 3, 2021 at 5:50 AM Alessandro Vesely <[e-mail]> wrote:
>
>> On Sat 02/Jan/2021 19:53:41 +0100 Douglas Foster wrote:
>> > Regarding this section:
>> >
>> >     Experience with DMARC has revealed some issues of interoperability
>> >     with email in general that require due consideration before
>> >     deployment, particularly with configurations that can cause mail to
>> >     be rejected.  These are discussed in Section 9.
>> >
>> > I suggest replacing it with a scope statement, such as this:
>> >
>> > DMARC checks are applicable when a message is received directly from
>> > the domain owner, or received indirectly from a mediator without
>> > in-transit modification.  As discussed in Section 9, these two
>> > criteria do not cover all legitimate email flows.   When a message is
>> > received indirectly with modification, DMARC cannot produce a usable
>> > result, and the message should be evaluated using alternate criteria.
>> >   When messages may have been forwarded with modifications, the
>> > algorithm for distinguishing between authorized and unauthorized
>> > messages becomes difficult to define.
>>
>>
>> I disagree.  Limiting the applicability of DMARC is not going to boost
>> its
>> actionable usage.  The above wording boils down to suggesting a sequence
>> of
>> operations as follows:
>>
>> 1:  check SPF.  If not pass then the message is indirect.
>>
>> 2:  check DKIM.  If not pass then the message is with modification.
>> Hence
>> DMARC results are not usable.
>>
>>
>> That would nullify the whole protocol.
>>
>>
>> Best
>> Ale
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>