Murray S. Kucherawy wrote on 2023-07-08 02:44:
"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.
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.
Regards, Matt _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
