RFC 7489 says that the p=(none|quarantine|reject) term is required (Section 6.3, page 17). We could preserve that requirement or state that p=none can also be taken as a default.
On Sat, Apr 23, 2022 at 1:50 PM John Levine <[email protected]> wrote: > It appears that Damian Lukowski <[email protected]> said: > > From the perspective of a decision problem, there are no unknown DMARC > tags. If there are syntax errors, then the whole thing is > >not a DMARC record, in particular it does not consist of valid tag-value > pairs and invalid tag-value pairs. The record > > > >> v=DMARC1; rua=mailto:[email protected]; garbage=101; more-garbage > > > >should not yield DMARC reports at all, as there is no DMARC record. > > The spec could be worded better, but you are clearly mistaken. > Anything that starts with "v=DMARC1;" is a DMARC record. > > >In my opinion, the spec should either stick to the grammar, or explicitly > and unambiguously define the parsing procedure. > > > >[1] "A DMARC policy record MUST comply with the formal specification > found in Section 5.4" > > Selective quoting is not helpful. What it actually says is: > > A DMARC policy record MUST comply with the formal specification > found in Section 5.4 in that the "v" tag MUST be present and MUST > appear first. Unknown tags MUST be ignored. Syntax errors in the > remainder of the record SHOULD be discarded in favor of default values > (if any) or ignored outright. > > As I said before, I think we should fix the spec to agree with the > practice. The ones I've seen accept an arbitrary list of tag=value > pairs, ignore any trailing garbage, and do not care about tag order > other than that v=DMARC1 has to be first. > > I definitely would not say that clients have to ignore records wth > syntax errors, since implmentations will ignore that and do what they > do how. > > Re Ale's question about a the tag registry. I'd make it FCFS rather > than Specification Required since there is no risk of running out of > tag names. I'd rather know about all the tags people use, even poorly > specified ones, so we can avoid name collisions. > > R's, > John > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
