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

[Dotzero <[e-mail]>]

On Sun, Apr 23, 2023 at 1:20 PM Hector Santos <hsantos=
[e-mail]> wrote:

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

It HAS NOT been 17 years for either DMARC (first published in 2011  and
first submitted to IETF as informational in 2015) or DMARCbis. Let's at
least use publicly available data points for time frames rather than time
frames pulled out of thin air.

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

No! Supporting and referencing an experimental specification which has
never gotten significant traction is the wrong way to go. If you believe
that ATPS is the right path then YOU should work to attract a wider range
of participants to use ATPS and then provide data back to IETF, whether
through an ATPS working group or a DKIM working group that is chartered to
undertake that work.

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

You don't even need a working group at this point to validate that ATPS
works and that it can scale in a workable manner. It has not been shown
that ATPS scales with regard to adds and deletes of individual tags. As you
quite rightly point out, ATPS was designed for ADSP, not DMARC. I have no
problem if you and others wish to experiment but you should do your
experiment first and then seek agreement from the wider community before it
gets embedded in another specification. Why should ATPS be granted special
consideration vs other proposals out there? It shouldn't.

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

SSP is long gone and failed. Referencing something which failed to gain
support many years ago is also not a path to go down.


> I don't think the above will take long to do and I believe will help
> resolve the conflict.
>

It doesn't resolve the conflict. As I stated above, if you believe in ATPS
then you need to attract a wider range of participants for your experiment,
including sending domains, receiving domains and intermediaries (and not
just mailing lists). Repeating "this solves the problem" is not data.

Michael Hammer