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

Reply via email to