On Wed, Apr 12, 2023 at 11:41 AM Todd Herr <todd.herr= [email protected]> wrote:
> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy <[email protected]> > 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'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? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
