On Sun 29/Sep/2024 23:16:46 +0200 Murray S. Kucherawy wrote:
[...]
There are still some steps we need to get through before this can be
published, and it's unclear how smooth of a ride that's going to be. There
will almost certainly be more feedback.
Here's my feedback about a few points. HTH.
In Section 2.1, under "High-Level Goals", there's a bullet that reads thus:
"Minimize implementation complexity for both senders and receivers, as well
as the impact on handling and delivery of legitimate messages."
Given the collision with indirect mail flows, which I don't think this
document actually improves relative to RFC 7489, do we feel like we met
this goal, at least the part after the comma? Should we revise this so we
don't draw fire for a failure here?
I think we reached consensus on the fact that DMARC is not yet ready to be
deployed out of the box (Sections 5.4 and 7.4). It's not an effective
improvement, but at least states the problem well.
In Section 2.4, "Out Of Scope", there's this bullet:
"Reporting or otherwise evaluating other than the last-hop IP address;"
...which reminds me that ARC is in an unresolved state. Is the plan to
ship DMARCbis without any particular reference to its use and "Update" it
in later? There's another reference to ARC later in the document as well.
Ditto. There's more work to be done.
Section 3.2.12 is the first reference to PSD. About PSD in general: This
document introduces this concept, as a significant change since RFC 7489.
Appendix C identifies it as a major change, which is good, but I'm
wondering if somewhere we might want additional text that describes the
likely interaction between Domain Owners relying on PSD and Receivers
relying on the old PSL way of doing things, or vice versa. Are there any
interoperability concerns?
I've been using DNS Tree Walk for a few months now, and only found one case
where it logged "Tree Walk from newsletter.nero.com finds newsletter.nero.com,
while PSL had nero.com: SPF identifier newsletter5.nero.com becomes not aligned
this way".
Section 4.5 says:
DMARC Policy Records are stored as DNS TXT records in subdomains named
"_dmarc".
Are those subdomains? Aren't they just records in the domain? I suspect
DNS people might get picky here.
The IANA page, after RFC 8552, calls them Underscored and Globally Scoped DNS
Node Names.
In Section 4.6, the SHOULD needs justification.
Something like /up to report generator's capability or capacity/?
In Section 4.7, just out of curiosity, how much have we observed use of the
"fo" tag in the wild?
For a side note, why does it say /This tag's content MUST be ignored if a "ruf"
tag (below) is not also specified/?
In fact, RFCs 6651/2 provide their own ra= tags to specify a reporting address,
so if fo= only uses "d" and "s" values, it would make sense to set fo= without
ruf=.
Requiring ruf= makes sense only if the only reports considered are those
described in dmarc-failure-reporting.
In Section 4.8, I think there's an ABNF ambiguity in that "dmarc-record"
ends with *WSP, but so does the optional "dmarc-sep" right before it.
Does it have to be unambiguous?
Also in Section 4.10, I don't know what the purpose of Step 3 is.
Same section, I think there's a problem with Step 7. If I'm following this
correctly, this query might return a single record containing "psd=n" and
there might still be one from Step 2 that contains "psd=y". This test then
fails because it's not true that "a single record remains", so the
algorithm continues. Steps 6, 7, and 8 are then repeated up to the limit
at which point the algorithm stops with two or more answers in the set. Is
that what's intended here? What does a filter do with that?
That description should define a subroutine GET_RECORD, which describes once
for all v=DMARC1 and uniqueness. /If a single record remains/ refers to that
subroutine. Obviously, repeating the steps, multiple records may be retrieved.
Step 2 differs from 7 in that psd=y on the starting point doesn't stop the
algorithm. It is the case of a PSO using its base domain as an identifier.
Section 4.10.1 says:
"Note: PSD policy is not used for Organizational Domains that
have published a DMARC Policy Record. Specifically, this is not
a mechanism to provide feedback addresses (rua/ruf) when an Organizational
Domain has declined to do so."
So back in Section 4.7, the formal part, should we say expressly that
"psd=y" MUST NOT be used with the "rua" and "ruf" tags?
Only ruf= is disallowed. PSOs may require aggregate reports.
Section 5.1.1, regarding SPF, says:
"... SHOULD be constructed to ensure that only those authorized sources can
get an SPF pass verdict."
Why is this only SHOULD when it's MUST for DKIM (Section 5.1.2)?
Because SPF has many more possibilities than DKIM. Several operators allow /24
or even larger blocks of IPs, not all of which are actually legitimate MTAs.
I think Section 5.3.1 should say more about multi-valued From and what MUAs
tend to do with it. Otherwise, this almost says "If you want to bypass
DMARC, just use a multi-valued From field." Are attackers not incentivized
to try?
+1!
Section 7.2 strikes me as something that isn't likely a novel discussion,
so is there any other DNS document we can think of where we can reference
the topic?
Should we say that TTL SHOULD be at least _one day_, save for experimenting
temporary values? Changing records during the day will likely confuse
aggregate report generators...
Same section: I also think -- and this is probably my most significant
piece of feedback for the WG -- that we need to include some discussion of
the fact that we are knowingly advancing to the Standards Track something
that has serious and well described interoperability concerns. This is
being done because (give reasons here). This could go here or in its own
section (definitely not in an appendix). RFC 6377 is available as a
reference to describe some of the disruption. Just as with the principle
behind Security Considerations sections, I think it's more important to
highlight that we know there are problems, but believe this is worth
publishing at Proposed Standard anyway.
IMHO, the only case where it makes sense to publish DMARC is if we are
committed to fix forwarding. ARC is a good tool, but it needs a policy to set
up trust between forwarder and receiver.
Same section: We're saying receivers MUST NOT reject based solely on the
DMARC result. I feel like we're pushing the interoperability problem onto
receivers here. What advice do we have for them around how to go about
doing this? What properties of a message should they be looking at to head
off this problem? Is anyone successfully doing this today?
I'm still not honoring DMARC, except for a few, explicitly flagged domains
which I know are serious about p=reject, such as, for example, paypal.com. The
filter also allows the opposite, to enable DMARC in general except for flagged
domains. (That per-domain flag is a relative integer, to be added to a global
enable-dmarc flag.) Is this a way to implement Sections 5.4 and 7.5?
Section 10.8 also talks about "periodically checking the DMARC Policy
Records, if any, of PSDs" but doesn't talk about how one might achieve
knowledge of where they are. Is this just caching of the ones you've
discovered?
Aren't there ICANN policies that (dis)allow publishing DMARC records?
jm2c
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
