+1 for what Barry proposes
", "time": "2022-07-28T20:18:29Z"}, {"author": "Seth Blank", "text": "Strong disagree as an individual
", "time": "2022-07-28T20:18:47Z"}, {"author": "Tim Wicinski", "text": "in the current doc the iana reg refers the \"psd\" flag to 7489 and not 9091. ??
", "time": "2022-07-28T20:19:45Z"}, {"author": "Tim Wicinski", "text": "https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-15#section-9.4
", "time": "2022-07-28T20:20:26Z"}, {"author": "Pete Resnick", "text": "What is the reason for your objection to the MUST NOT?
", "time": "2022-07-28T20:24:06Z"}, {"author": "Pete Resnick", "text": "For @Seth Blank , that was
", "time": "2022-07-28T20:24:23Z"}, {"author": "Pete Resnick", "text": "\"Understand what you are doing\" is equivalent to \"SHOULD NOT\".
", "time": "2022-07-28T20:25:41Z"}, {"author": "Rolf Sonneveld", "text": "Is this not something for an A/S document?
", "time": "2022-07-28T20:25:56Z"}, {"author": "Pete Resnick", "text": "@Rolf Sonneveld we combine A/S with T/S all of the time.
", "time": "2022-07-28T20:26:29Z"}, {"author": "Murray Kucherawy", "text": "A nit: We (the IETF) didn't publish RFC 7489. The ISE did.
", "time": "2022-07-28T20:26:39Z"}, {"author": "Tim Wicinski", "text": "The outside world does not see any differences
", "time": "2022-07-28T20:28:10Z"}, {"author": "Pete Resnick", "text": "We have voluntary standards. People violate the TCP retransmission rules in some cases too. But they MUST NOT do that either.
", "time": "2022-07-28T20:29:15Z"}, {"author": "Trent Adams", "text": "We have some data on ARC - can address
", "time": "2022-07-28T20:32:01Z"}, {"author": "Pete Resnick", "text": "And let's be clear, it's a \"MUST NOT use p=reject when you don't intend to prevent forwarding through mailing lists or other non-transactional email.\"
", "time": "2022-07-28T20:38:13Z"}, {"author": "Pete Resnick", "text": "It's not \"MUST NOT use DMARC at all\".
", "time": "2022-07-28T20:38:31Z"}, {"author": "Seth Blank", "text": "@Pete Resnick what I'm trying to say, for many companies, the value of p=reject is far higher than that of the damage to mailing list and other dkim-breaking traffic. Telling them MUST or SHOULD NOT is counterproductive, because it's their choice. We should inform them of the potential impact, but it doesn't feel like normative guidance is useful when it's really an option of organizational policy.
", "time": "2022-07-28T20:40:53Z"}, {"author": "Pete Resnick", "text": "@Seth Blank I would understand if you were saying you'd prefer SHOULD NOT because (to quote 2119) \"there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing\", because that's pretty much what you're saying. I don't understand why you reject SHOULD NOT.
", "time": "2022-07-28T20:43:53Z"}, {"author": "Seth Blank", "text": "I can be convinced of SHOULD NOT. I remain deeply opposed to MUST NOT, and would prefer informative language to normative language on this matter. I also hear I may be in the rough ;-)
", "time": "2022-07-28T20:44:34Z"}, {"author": "Pete Resnick", "text": "I will equally understand if MUST NOT ends up in the rough.
", "time": "2022-07-28T20:45:35Z"}, {"author": "Tim Wicinski", "text": "i filed my nit as a git issue
", "time": "2022-07-28T20:46:47Z"}, {"author": "Rolf Sonneveld", "text": "What is meant by \"Note that the force of these words is modified by the requirement level of the document in which they are used.\" in RFC2119? Does this mean that a 'MUST NOT' in a Standard Track weighs more than in an \"Informational\"?
", "time": "2022-07-28T20:48:32Z"}, {"author": "Seth Blank", "text": "Do we need to discuss the rfc6973 impact on failure reports?
", "time": "2022-07-28T20:49:51Z"}, {"author": "Seth Blank", "text": "or the fact that pretty much no major mailbox sends them?
", "time": "2022-07-28T20:50:15Z"}, {"author": "Murray Kucherawy", "text": "I would.
", "time": "2022-07-28T20:50:30Z"}, {"author": "Murray Kucherawy", "text": "@Rolf: That's how I interpret it.
", "time": "2022-07-28T20:50:48Z"}, {"author": "Rolf Sonneveld", "text": "@Murray, thanks. Isn't it a bit weird that \"requirement level\" is mentioned twice in RFC2119, once in the title and once in the text, without it being explained in the doc?
", "time": "2022-07-28T20:52:05Z"}, {"author": "Pete Resnick", "text": "@Rolf Sonneveld See RFC 2026 for a discussion of requirement levels.
", "time": "2022-07-28T20:53:42Z"}, {"author": "Rolf Sonneveld", "text": "@Pete, ah, thanks
", "time": "2022-07-28T20:55:14Z"}, {"author": "Ricardo Signes", "text": ":wave:\ud83c\udffd
", "time": "2022-07-28T20:55:40Z"}, {"author": "Pete Resnick", "text": "@Rolf Sonneveld We don't really use that stuff anymore, but that's what it was referring to.
", "time": "2022-07-28T20:55:53Z"}]