I would be content with language that says: If an evaluator detects a DMARC record without a policy tag, it MAY reject the record as invalid or it MAY treat the record as equivalent to p=none. Consequently, domain owners SHOULD include a p= tag, as the recipient action is otherwise unpredictable..
DF -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Monday, November 09, 2020 7:15 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Optional p= makes no sense On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote: > On 11/7/20 1:11 AM, Alessandro Vesely wrote: >> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >>> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >>> >>>> It makes no sense to allow "p=" missing. Why would we suggest >>>> that all existing implementations alter their code to tolerate >>>> additional unnecessary complexity, rather than requiring domain >>>> administrators to key a few more characters so that code changes will not >>>> be necessary? >> >> >> Are there really implementations that choke on missing p=? >> >> How about "v=DMARC1; p=none; p=quarantine;"? > > > I'm pretty sure both cases would be invalid as DMARC policy records, > in which case they should be ignored. I don't think so. The current draft says: 6. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" tag that is not valid, then: 1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing; > If an implementation is trying to do something with invalid records > like these, particularly one with multiple "p=" tags, then that would > be a problem. Invalid or repeated p= tags are a problem, but possibly they don't completely disqualify a record. So the question becomes "How does a missing p= tag differ from an invalid one?" This is a marginal question, to define the syntax of a DMARC record as simply as possible (but not simpler). I added a comment to ticket #7[*] with a proposed syntax. IMHO the spec should just mention undefined behavior or some such, without trying to impose overly strict commitments —given that parsers have to deal with the possibility of non-conforming records anyway. This question is not related with splitting policy into its own document. Best Ale -- [*] https://trac.ietf.org/trac/dmarc/ticket/7#comment:4 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
