[dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos <[e-mail]>]

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