On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander <mail= 40wander.scie...@dmarc.ietf.org> wrote:
> > "SHOULD" leaves the implementer with a choice. You really ought to do > > what it says in the general case, but there might be circumstances where > > you could deviate from that advice, with some possible effect on > > interoperability. If you do that, it is expected that you fully > > understand the possible impact you're about to have on the Internet > > before proceeding. To that end, we like the use of SHOULD [NOT] to be > > accompanied by some prose explaining when one might deviate in this > > manner, such as an example of when it might be okay to do so. > > The elaborated Interoperability Considerations in Barry's proposal gives > the implementer guidance to understand the impact. In my understanding, > SHOULD is ought to be followed, unless the implementer has good reasons > not to. The burden of justification is on the implementer, not on the spec. > I would agree, but I also think the more information and guidance you put in the hands of the implementer -- especially around something potentially thorny, like this -- the better your document's quality, because the better the outcome will be. > > Does anyone have such an example in mind that could be included here? > > Specifically: Can we describe a scenario where (a) a sender publishes > > p=reject (b) with users that post to lists (c) that the community at > > large would be willing to accept/tolerate? > > The scenario I have in mind is a business domain with a high demand for > protection from exact domain spoofing and a low to no demand for list > communication. Note the wording in Barry's proposal: "users who *might* > post messages to mailing lists" (not: "users that post to lists"). > > I wouldn't include such an example in the RFC, because I don't see a > discussion to this extent for any of the other SHOULD requirements in > the document. > I think you just explained why including such guidance is a good idea. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc