Re: [dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Douglas Foster <[e-mail]>]

I mentioned you to acknowledge authorship, not to isolate.   Your text
focused on the mailing list response, which is a separate section from the
domain owner warning that Barry raised and Scott developed.   As I said, I
think both perspectives need to be addressed, because domain owners will
ignore the caution and mailing lists will have to decide how to respond.
Evaluators need to be addressed because
they are the ones that ultimately block messages that their users want
delivered.

But I need to clarify whether I understand your point.   What I am hearing
is:

   - For the short term, mailing lists should refuse postings from
   DMARC-enforcing domains.   That position can be relaxed only if all
   participating domains have agreed to ignore DMARC Fail for messages from
   the list  (Ale floated some ideas about that approach.)
   - For the longer term, we need a non-DKIM method for delegating rights
   to a third party.

We have a "mailing list problem" because mailing lists have been unwilling
to operate with that limitation.   It is perceived as, "Sorry that you lost
half your user base, you just need to buck up and accept the new reality."
  I agree that it solves the problem, but I have to acknowledge that the
solution has been repudiated by most of those who would need to embrace
it.   You may be the exception.

You talk about "incomplete protocol" as if this is a commonly understood
and accepted term.  I interpret it to mean a third-party authentication
method other than DKIM.  DKIM does serve for third-party authentication
where it has been embraced and deployed.   So the issue is that it has not
been practical for many situations and we do need another option.

For the longer haul, I agree that we need a new authentication method.  The
method needs to match the context, which means that the delegation should
be user-to-domain.   List subscriptions are a user-level activity, and a
user-level delegation does not undermine domain-level DMARC, while it
continues to protect the user from impersonation by anyone other the list
domain.   Original ATSP is too much like DKIM, but ATSP extended to the
user level represents new functionality.    What remains to be seen is
whether a viable design can be produced.

Any new authentication protocol requires a way for receivers to indicate
participation, or it encounters the same problems we have with ARC, which
is the continued use of From Rewrite because lists do not know that Rewrite
is not required.

Doug



On Sat, Apr 29, 2023, 11:02 AM Hector Santos <hsantos=
[e-mail]> wrote:

>
> > Given that lists are expected to (A) continue making content changes,
> and (B) continue accepting all comers, I think we need to embrace From
> Rewrite as a necessary consequence of A and B.    Unlike Hector, I don't
> have a problem with From Rewrite because the act of altering the content
> makes it a new message, and the modifying entity becomes responsible for
> the whole thing.   So we need a caveat to list owners which lays out the
> real risks and the better alternatives.
>
>
> Douglas,
>
> Just a few points.
>
> It is more accurate to state, "Unlike others," because I am not the only
> one who has a problem with altered mail authorship, and worse, when done
> for the purpose of a security teardown it potentially introduces a new
> security threat with Display Name attacks.  I believe I am “IETF” correct
> to raise this security concern where IETF security folks would agree.
>
> It is often stated that it is unfair to MLS/MLM folks who have worked
> unchanged for over 30+ years to be required to change.  Please understand I
> have a commercial MLS product since 1996 and I don’t like changes just like
> the next MLS developer. I’ve extremely conservative but I do adapt when
> necessary. My MLS is a legacy product but it is still actively supported.
>
> Well, for the MLS or MLM refusal to adopt the protocol, the refusal to
> adopt measures known to resolve the DKIM secured with Policy mail stream,
> caused an immediate need by one MLM to create a hack to alter list
> submissions from restrictive domains. It resolved the immediate problem.
> The MLM could have adopted subscription/submission controls as outlined in
> 2006 and discussed many times in the WGs. It  was not  unknown. These
> correct methods would have pushed the burden back to the domain seeking
> exclusive mail security once they began to publish and honor p=reject. The
> MLM could have supported any of the many ADID::SDID association
> authorization proposals too, but it did not. So here we are with the DMARC
> rewrite problem where in my view, needs to be explained and corrected.
>
> The "new message" angle is one view, but not the definitive one to suggest
> it is okay to alter list submission copyrighted authorships. It is not a
> normal thing to do, but what you can do as an MLS/MLM developer depends
> widely on the type of list distribution. If you are just broadcasting to a
> list of people as a read-only list, then the preparation of required
> headers is a legitimate instance where it completes a new secured message
> with the proper secured business addresses.
>
>
> —
> HLS
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>