On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr <todd.herr= > 40valimail....@dmarc.ietf.org> wrote: > >> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy <superu...@gmail.com> >> wrote: >> >>> I've been thinking about the point a few people have made now that DMARC >>> has two actors that cause the problem: Those who "blindly" apply >>> "p=reject", and those who advertise "p=reject". You do, indeed, need two >>> to tango; enforcement doesn't happen without an advertising sender and a >>> participating receiver. Maybe any "MUST NOT" advice we provide needs to >>> cover both ends. We need to be careful about admonishing participating >>> receivers though. What would we say to them about how to be selective in >>> application? >>> >> >> I'd argue that we have language already that advises receivers to be >> selective in application. The second paragraph of section 5.8, Policy >> Enforcement Considerations, currently reads as follows in DMARCbis: >> >> Mail Receivers MAY choose to accept email that fails the DMARC mechanism >> check even if the published Domain Owner Assessment Policy is "reject". In >> particular, because of the considerations discussed in [RFC7960 >> <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#RFC7960>], >> it is important that Mail Receivers SHOULD NOT reject messages solely >> because of a published policy of "reject", but that they apply other >> knowledge and analysis to avoid situations such as rejection of legitimate >> messages sent in ways that DMARC cannot describe, harm to the operation of >> mailing lists, and similar. >> >> >> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider >> >> Might that language be made stronger? Sure. Might it or other text >> include mention of ARC as a possible solution? Maybe. >> > > Right, thanks for the reminder. > > I think part of the problem might be that blanket observance of "reject" > is already commonplace. There's also very little in the way of algorithms > or text guidance to indicate to receivers how they're supposed to know when > it's safe to actually reject. > I'm not sure it's true to say blanket observance of "reject" is commonplace. Both Gmail and Microsoft will override p=reject on a regular basis due to reasons known only to them. As for when it's safe to actually reject, I'm not sure that the full effect of policy changes can ever truly be known or predicted before they're implemented; one usually only learns the full impact after implementation. Back when I worked in email ops, the volume of customer complaints was a pretty good indicator to tell me that a decision I'd made had resulted in users not getting wanted mail (or getting too much unwanted mail). There was no hard and fast rule, of course, nor should we ever expect that there will be, but each organization I'm sure has some threshold for realizing that a new change's impact is a net negative, and a process for deciding whether or not to roll back a change if it does prove to be a net negative. It is possible, of course (or should be) to simulate the effect of changes prior to implementing them and use the information gathered to determine whether or not to go forward. When the decision under consideration is "should we honor p=reject?" I would study the inbound traffic for a reasonable period of time (maybe a couple of months or more) and track how much mail would've been rejected (perhaps on a per-domain basis) and to the extent my system allowed, what percentage of that mail was engaged with, and how (spam complaints, opens, deleted without opening, forwarded, etc.). Obviously, such engagement tracking might be beyond the capability of some mail receivers, but that's how I'd want to approach the problem. Might the above two paragraphs contribute to additional text to add to this document in section 5.8? > > >> >> I've also been thinking about ways to push the burden back on the >>> advertisers. Imagine we have some kind of signaling mechanism that MLMs >>> can take advantage of indicating to them that the author is using a strong >>> policy, and so it would be possibly a bad idea for the MLM to accept, >>> mutate, and re-send this message. This could be a header field or an SMTP >>> extension (though the latter is complex to get right in a store-and-forward >>> system). The MLM can then decide if it is willing to pass the message >>> unmodified to the list, or reject it with an error like "The policies of >>> this list require modification of your message, which violates your >>> domain's apparent policy. Your submission therefore cannot be accepted. >>> Please contact your support organization for further assistance." There's >>> never an opportunity for the collateral bounce to occur if the message is >>> never distributed, and the author domain has to either soften its policy or >>> separate its regular users from its transactional stuff somehow. >>> >>> This avoids the "collateral" and "persistent" damage issues I raised in >>> a separate post. It still requires the MLMs to do something new, but >>> avoids the need to implement any of a variety of unsavory mutations. MLMs >>> could also determine this by querying the current DMARC policy of the >>> author's domain, to be sure, so it's a choice between MLMs looking for a >>> header field (which they already know how to do) or becoming DNS-aware >>> (relatively simple, but pulls in some complexities and dependencies they >>> may not want). >>> >> >> My preference here would be to add text for Domain Owners to make them >> understand the ways that p=reject might cause some mail using their domain >> to not make it to its destination, with "mailing lists might reject your >> mail" being one such example. >> > > And a good example, given it's the most obvious one. But is it enough to > say that and nothing else? What about MLMs actually doing something like > this? > > Early in the thread that Barry started (Subject: Proposed text for p=reject and indirect mail flows) I proposed some text to expand on section 5.5.6, Decide Whether to Update DMARC Policy. I submit an updated version of that text again here as a starting point for discussion. 5.5.6 Decide Whether 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. The policies "reject" and "quarantine" are more effective than "none" for accomplishing the chief goal of DMARC, namely to stop the exact-domain spoofing of the domain in the RFC5322.From header. However, experience has shown that policies of "reject" and even "quarantine" can result in the disruption of indirect mail flows and result in damage to the operation of mailing lists and other forwarding services. [@!RFC7960] and [@!RFC8617] and Section 5.8, below, all discuss this topic and/or possible strategies for addressing it. Because of these challenges, some domains may prefer to remain at a policy of p=none or perhaps go no further than p=quarantine. Each Domain Owner will have to use the data collected from aggregate reports sent its way to determine what impact on its users a policy other than p=none might have. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
