*Note: The following is a general rule of thumb for me.*
From my functional specification protocol language coding standpoint:
MUST --> NO OPTION. Technically enabled with no switch to disable.
SHOULD -> OPTIONAL, Default is ON, enabled
MAY --> OPTIONAL, Default is ON or OFF depending on implementation
With the special RFC documentation format designed/written for a very
wide audience from managers, system admins, coders, engineers, etc, it
offers semantics with lower and upper case guidelines. sometimes
purposely ambiguous (to keep it open ended) and in the IETF RFC, we
have used the UPPER CASE language as a way to create code especially
with standard track items.
Those who choose to ignore the UPPER CASE interop advice often risk
having the proverbial book thrown at them.
With lower case semantics, this has been my overall implementation
methods:
may, should --> may be implemented as options as with upper case
must --> may be implemented and enabled with hidden option to disable.
--
HLS
On 7/8/2023 12:49 PM, Richard Clayton wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message<CAL0qLwY-UajkOV_CJ4_L9kS+6N=_+cudfkvpvyk84ooadjw...@mail.gma
il.com>, Murray S. Kucherawy<superu...@gmail.com> writes
Some of my IETF mentors (ahem) taught me some stuff about the use
of SHOULD [NOT] that have stuck with me, and I'm going to pressure
test this against that advice.� Let's see how this goes.� :-)
"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.
I noted that one of the earlier messages which endorsed MUST NOT said
that of course some people might know better -- which is what I always
understood SHOULD NOT was for !
� 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.
not so much "OK" as "necessary". Yahoo's original statement (I'm
prepared to name names rather than pussyfoot around this) on the
deployment of p=reject is discussed here:
https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/
and I believe it is widely understood that it was particularly deployed
to counter the "address book spammers" of the time. These bad guys
originally persuaded people to open their email by forging it to appear
to come from their friends (having compromised relevant address books).
They then moved on to just using random identities from the same domain
as the recipient. This led a great many Yahoo users to believe that a
great many other Yahoo users had been compromised, leading to a
significant loss of faith in the integrity of the platform.
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?
So the example you seek might be phrased along the lines of when failing
to set p=reject means that significant quantities of forged email will
be delivered and this will cause damage.
Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too
strong, mailing lists (and other forwarders that mangle email) have been
coping with p=reject for nearly a decade -- so that trying
(ineffectually in practice) to make their lives easier at this point is
a snare and a delusion.
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
