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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
