We should probably add a "v=counter" to the DMARC syntax. But the
odds are good that will screwed up too in duplicate records.
I think my software will read the first encounter of a DMARC text
record and not seek for an "override" that could follow. Not going to
waste time to verify it.
We could add language in the future specification which suggest when
duplicates exist, the harshest record (p=reject) will be used.
--
HLS
On 12/19/2017 1:54 PM, John Levine wrote:
In article <20171219183616.ga6...@marwnad.com> you write:
Section 6.6.3, Policy Discovery.
"If the remaining set contains multiple records or no records,
policy discovery terminates and DMARC processing is not applied
to this message."
Oh, look at that. Thanks.
For that matter, what if anything does this mean?
_dmarc.example.com IN TXT "v=DMARC1; p=none; p=reject"
In 7489 it says "DMARC records follow the extensible "tag-value"
syntax for DNS-based key records defined in DKIM [DKIM]." I hope that
means they follow the DKIM rule that duplicate tags make the whole
record invalid, but that could be clearer.
The definition of tag-value syntax in [DKIM] section 3.2 says "Tags
with duplicate names MUST NOT occur within a single tag-list; if a tag
name does occur more than once, the entire tag-list is invalid." This
language could be repeated in the DMARC specification, but I don't see
any real reason to do so.
There's also a formal ABNF definition in 7489 section 6.4 which shows
that duplicate tags aren't allowed.
I see that, but unfortunately the DMARC ABNF doesn't match the prose.
Section 6.3 says that unknown tags are ignored, but the ABNF syntax
doesn't allow them.
R's,
John
_______________________________________________
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
