I would like to make the receiving advice stronger *also*, yes. In particular, I would change the SHOULD NOT to MUST NOT, and I would add text that suggests that it's a particularly bad idea to react to p=reject for domains that are known to host email addresses for the general public, and expand on the reasons why.
I don't think that eliminates the need for strong advice to senders as well. Barry On Thu, Apr 13, 2023 at 11:07 AM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
