On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones <s...@crash.com> wrote:
> On 10/20/23 12:35 PM, Murray S. Kucherawy wrote: > > (1) As written, the text says (to me) that the handling of a message might > change depending on this mapping of a broken value to "none", but only if > "rua" is present; absent "rua", the record is treated as junk and DMARC > doesn't apply. > > It's not so much changing the handling as changing the reporting. > Yes, I think that was probably the intent of the logic branch here, but that's not how it reads. > > So then, maybe we wind up with something like this: > > PROPOSED versus draft 28 section 4.7: > > ======== > If a retrieved policy record does not contain a valid "p" tag, or > contains an "sp" or "np" tag that is not valid, then: > > * The Mail Receiver MUST act as if a record containing "p=none" was > retrieved and continue processing; > > * The Mail Receiver MAY note the invalid "p", "sp", or "np" tag > in the optional "error" field of the informative section of the > DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting]; > > * If there is no "rua" tag, or if it does not contain at least one > syntactically valid reporting URI, the Mail Receiver effectively > applies no DMARC processing to this message. > ======== > > And if somebody wants to argue against including the third point, I would > offer that it may be better to be explicit that to repeat this exercise in > a future WG. > I think the first bullet should include the word "only", otherwise it looks like you're replacing a faulty "p" tag but not the others. I think the MAY in the second bullet should be a lowercase "should". I think the third bullet after the comma should read more like "the Mail Receiver does not include this message in reporting in any way", because the current language ties it back to handling which, as you said, is already decided. -MSK, participating
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
