Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos <[e-mail]>]

On 4/28/2023 5:19 AM, Alessandro Vesely wrote:
 > On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote:
 >> Mailing list changes to ameliorate damage due to DMARC are in no 
way an improvement.  Absent DMARC, they would not be needed at all.
 >
 > +1

In my view, when an incomplete protocol is introduced, it creates 
gaps. If there are no guidelines for addressing these gaps in a 
graceful and elegant manner, solutions can vary widely. As developers, 
it's important to have the ability to make adjustments to our software.

Here are a few suggestions to "ameliorate damages" caused by an 
incomplete protocol:

1) Address the gaps with proper protocol negotiation guidelines and a 
well-defined state machine. This includes addressing third-party 
signers and providing guidance for groupware, one-to-many, mailing 
lists, and newsletter distribution mailers. This would make the 
protocol more complete.

2) If option #1 is not viable and continues to be a non-starter with 
the editor of this standard track bis document, the document's status 
and endorsement become technically challenged in many ways. It then 
becomes critical to have a Field Operations status report on a) DMARC 
p=reject problems, b) current problem mitigations, and c) any new 
security threats introduced by the mitigations, particularly with a 
DMARC Security teardown.

There aren't many options for MLS developers when dealing with an 
incomplete protocol.

I have been developing mail software since the '80s, with products 
such as Silver Xpress, Platinum Xpress, Gold Xpress, and Wildcat! 
These early experiences have informed my current understanding of the 
challenges in integrating DMARC into systems.

Regarding rewrite, we don't want to promote it, but it may now be 
necessary to describe it as a new potential "Display Name" security 
threat. However, there are legitimate situations where a rewrite is 
both technically necessary and ethically acceptable. For example:

A MLM Newsletter list domain MUST have a From: domain example-biz.com 
for security. This is a read-only list, and only a few authorized 
submitters can post newsletters. They use their ESP's MUA to submit 
using their ESP's domain address.

In this case, it is about the content payload, not the submitter. This 
is a legitimate situation where a complete rewrite of the incoming 
header is warranted. In the case of DMARC, it becomes necessary. The 
ESP's headers are removed, and the RFC5322 is applied for a secure, 
unambiguous result. It would be as if the customer logged into wcWEB 
and posted the newsletter directly in their MLM List storage area, but 
they prefer to do it via ESP email.

Therefore, rewrite can be described as BAD when used intentionally to 
break down DMARC security or GOOD when used to create DMARC secured 
distribution.

Thanks

-- 
Hector Santos,
https://santronics.com
https://winserver.com