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

[Alessandro Vesely <[e-mail]>]

On Sun 03/Jan/2021 20:56:59 +0100 Douglas Foster wrote:
> 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.


Let me object to the consistency of this point of view.  Unlike PGP, DMARC is 
not designed as an end-to-end protocol.  The only way that a user could decide 
on a per-message basis whether or not her message should be subject to which 
policy would be to have a variety of domains configured with each policy and 
then set her From: header field appropriately.  Clearly not a viable mode of 
operation.

A general purpose domain can have email users and some transactional mail as 
well.  DMARC has to be configured to suite all of them.  There are special 
domains, which are highly abused.  They had to direct their users to use 
subdomains for non-transactional mail.  The need to do so can be considered a 
DMARC defect, IMHO.


> 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.


Having advertisements come /From: advertiser/ is a goal.


> What is clear is that by this definition, mailing list messages are
> legitimate, and yet are incompatible with DMARC.


No, MLM messages with rewritten From: are fully compatible.


> 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.

Not sure.  Spam shouldn't be forwarded.


> 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.


It is much simpler if the sender is DMARC-aware and sends messages that pass 
DMARC.  There is a plethora of legacy devices and servers that send plain old 
mail.  They are a problem and need to be identified and somehow gatewayed or 
delivered skipping DMARC processing.


> 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.


Hiding depends on how you rewrite and forward.  Receivers can examine ARC 
chains and/or undo MLM transformations so as to deliver a fully meaningful 
message header.


> 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.


Girl Scout troops will inevitably fall in the not forwarded category.  ESP 
messages, instead, should come /From: ESP/.


> 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.


I wish it ends up in something deterministic that can be used by small and 
large providers alike.


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


Some people push for domains to migrate toward a strict policy.  They assume 
that p=none is a transitory status.  I wouldn't call that "overselling", as, in 
fact, having p=none currently provides the best deliverability.  Yet, p=none 
makes DMARC non-actionable, which I think is a limitation.


Best
Ale
--