On 4/23/2023 6:10 AM, Alessandro Vesely wrote:
Meanwhile, digressions about ATPS and similar schemes can help casting some light on future evolution. From: rewriting cannot be the final solution; it is a temporary hack. Digressions don't slow down the publication, as discussions about actual text quickly prevail. They are just a mean to help convergence toward a common vision of the future.
With each year, that "temporary hack" becomes the new normal and it will be harder to clean up. It is not the right way and I don't its too late to reverse. However, it has been 17 years and DMARCbis is not finished without some clean up in this area.
First, Section 4.4.3 should have text on using extended tag methods to provide 3rd party authorization methods. Just add the RFC 6541 abstract or version of it:
ATPS [RFC6541] is an experimental specification proposed which adds a extended tag "atps=" allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. ATPS was designed for ADSP. There is interest to apply this tag to DMARC to help deal with unchecked but authorized resigners false positives.
Second, there are possible outcomes with members using restrictive domains:
1) Legacy MLS/MLM, unaware of protocol, unchanged author domain, submission mail integrity is broken due to long time practice of body and subject changes, can cause members of a list to be auto-unsubscribed when their receivers begin to honor p=reject and reject mail integrity DKIM failures.
2) Protocol Awareness, honoring the policy, constraining subscription and submissions to unsecured submissions. Restrictive domains not acceptable for list submissions. Note: It is possible to allow a Read-Only List Member concept.
3) Protocol Awareness, not honoring policy and tearing down the author security, replacing with unsecured distribution.
The correct way for any protocol is to close security loopholes. In this case, recommend #2 using Subscription and Submission controls. Let the author domain figure it out. DMARCbis MUST recognize if the intent of the domain is to clean up their brand, by implementing hard failure rejects at both SPF and DMARC, then it should recommend handlers SHOULD honor the policy of the domain or be prepared for the possible false positives.
I can understand why DMARCbis's editor does not want to document rewrite, but imto, can't be ignored anymore. The details of a rewrite can be quickly outlined. To help the RFC process, maybe DMARCbis could refer to the Functional Specifications of SSP (RFC5016) Section 5.3, Item 10 which basically reinforces the idea that local policy ALWAYS prevails and it is quite possible there will be undesirable tearing down of secured submissions. One possible mitigation is to replaced it with a secured rewriter with a p=reject policy.
I don't think the above will take long to do and I believe will help resolve the conflict.
-- Hector Santos, https://santronics.com https://winserver.com _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
