> I believe in the situation where standard is absolutely clear like this,
> any implementer must strictly follow the standard. Otherwise, it can
> lead to unpredictable behavior and security issues.
Sorry, I meant to mention this in my previous response. It's one thing
when there's wiggle-room or lack of clarity in the standard. It's quite
another when things are clear, as is the case here.
> Example: there are absolutely legal situations where non-trusted or less
> privileged side can partially control the name and/or content of the DNS
> record. I can provide users or customers with possibility to register a
> hostname and TXT record in my zone but I want to prevent them from
> corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT
> record content. Non-standard behavior of DMARC implementation can allow
> to bypass this filtering.
> While this example doesn't seem realistic, I can demonstrate quite
> realistic ones. For example, a minor relaxation for ARC version check
> can lead to DKIM signature spoofing, compromising DMARC as a result. For
> DMARC DNS record itself, realistic scenario may appear in the future.
> We already have a lot of problems in-the-wild because of standards
> relaxations, e.g. it's usually possible to bypass DMARC which relies on
> RFC5322 via malformed From: due to fact invalid From: header is
> generally accepted and parsing From: header for DMARC validation and for
> visual representation is usually made by different pieces of code with
> different behavior.
Exactly. This is a security protocol and there are real security implications
of doing stuff like this. Another reason to Just Say No.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
