Re: [dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows
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 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 t
Re: [dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows
> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows
Thank you, Scott. You have done a great job of encouraging progress on a topic with strong emotions. I believe we need warnings to all three participants: - One to domain owners, which Barry started - One to lists and other forwarders, for which Hector has provided a starting point - One to evaluators, which is where I tried to steer us. They are not mutually exclusive. Each party has to deal with the "fait accompli" represented by the messages that it receives, and makes its own choices. For domain owners, I am comfortable with the language above, and some of the other recent variants. I prefer the ones that focus on guidance, rather than "MUST NOT", but I understand the emotion that leads to MUST NOT. For lists, I need to start by expressing my surprise that unsubscribing an innocent bystander is the most serious consequence. It is very risk to send a message when you expect the recipient to classify it as malicious. The expected response should be blacklisting by the server organization, which includes all of its clients, which is possibly coupled with an RBL listing. In short, the consequences can be disastrous and SHOULD NOT be undertaken. Mailing lists have this problem because of making changes, but any forwarder has this problem if they forward a message that has DMARC enforcement, but no signature, due to domain owner errors. 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. For evaluators, we need a warning that says DMARC is not perfect. Evaluators should expect to see: - acceptable impersonation from certain sources, - lost credentials due to relay after mailing list additions to a message, - lost credentials due to forwarding after spam filter additions to a message, - lost credentials due to forwarding of unsigned messages. While automatic rejection on p=reject is implemented by some evaluators, it will always be sub-optimal.The better choice is to quarantine with prioritized review, so that real threats can become complete blocks on the responsible party, and non-threats can be corrected with local policy adjustments. Doug Foster On Fri, Apr 28, 2023 at 9:28 PM Scott Kitterman wrote: > On Tuesday, April 25, 2023 2:27:18 PM EDT Scott Kitterman wrote: > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > > I raised this issue in the DMARC session in Vienna, and have let it > > > sit for a while so as not to derail other discussion. As we're pretty > > > close to finished with the DMARCbis document, I'd like to raise it > > > again, this time with specific proposed text for us to discuss. > > > > > > And so: > > > > > > OLD > > > > > >5.5.6. Decide If and When to Update DMARC Policy > > > > > >Once the Domain Owner is satisfied that it is properly > authenticating > > >all of its mail, then it is time to decide if it is appropriate to > > >change the p= value in its DMARC record to p=quarantine or p=reject. > > >Depending on its cadence for sending mail, it may take many months > of > > >consuming DMARC aggregate reports before a Domain Owner reaches the > > >point where it is sure that it is properly authenticating all of its > > >mail, and the decision on which p= value to use will depend on its > > >needs. > > > > > > NEW > > > > > >5.5.6. Decide If and When to Update DMARC Policy > > > > > >Once the Domain Owner is satisfied that it is properly > authenticating > > >all of its mail, then it is time to decide if it is appropriate to > > >change the p= value in its DMARC record to p=quarantine or p=reject. > > >Depending on its cadence for sending mail, it may take many months > of > > >consuming DMARC aggregate reports before a Domain Owner reaches the > > >point where it is sure that it is properly authenticating all of its > > >mail, and the decision on which p= value to use will depend on its > > >needs. > > > > > >It is important to understand that many domains may never use > > >policies of “quarantine” or “reject”, and that these policies are > > >intended not as goals, but as policies available for use when they > > >are appropriate. In particular, “reject” is not intended for > > >deployment in domains with users who send routine email, and its > > >deployment in such domains can disrupt indirect mail flows and cause > > >damage to operation of mailing lists and other forwarding services. > > >This is discussed in [RFC7960] and in Section 5.8, below. The > > >“reject” policy is best reserved for domains that send onl
