Replying to just a few of these: On Mon, Sep 30, 2024 at 10:58 AM Alessandro Vesely <[email protected]> wrote:
> > 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. > OK, but are we fine saying an explicit goal of this work was X, and this document does not meet that goal? > > 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? > I think it's supposed to be, but I can't recall how hard of a rule that is. > > 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. > We need to say so. Without context, this reader at least was left wondering. > 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... > Rather than making up a guideline and attempting to justify it, I was thinking that some other thing in the IETF's past must have tackled this subject already, and we can just reference that discussion. > > 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? > Maybe, maybe not; do we have to complicate this work with that discussion? -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
