-----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
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBZKmTft2nQQHFxEViEQJ4zACfUiVCRzGjK68phKi73kl0kg0CKnAAnjAB
ft3PPkV73wIPjvYs7tCjrCsm
=EUgy
-----END PGP SIGNATURE-----
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
