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= [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
