On Fri 06/Dec/2024 21:28:02 +0100 John R Levine wrote:
On Fri, 6 Dec 2024, Daniel K. wrote:
Is the whole size discussion so hypothetical that we should even remove
the "MAY send a message saying you have a report that couldn't be sent"
part?
I guess your 'it's obsolete and reporters aren't expected to pay
attention to it' below is an answer.
All else being equal I prefer not to change stuff if we don't have to. This
doesn't seem useful but it's also harmless.
The initial part of Section 2.5 is mostly a leftover from Section 7.5.1 of RFC
7489. It should be rewritten entirely, otherwise it sounds ridiculous.
The syntax below is fine, but the text in aggregate-reporting should explain
it, rather than ignoring that the other document obsoleted the size limit.
The second sentence of the first paragraph in Section 2.5 must be removed.
The second paragraph, raving about short messages that nobody can parse, can be
removed entirely.
I think the third paragraph, about how a rua might specify a secure transport
("mailtos"?) can be removed as well. Even considering a possible http or https
transport, its meaning is totally obscure.
For integrity, we should add an historical explanation sentence about our
obsoleting the exclamation point and repeating the hint to ignore the
characters that follow it. Additionally saying that possible size problems
should instead be tackled by increasing the sending frequency might hint at why
we also obsoleted ri=.
We could go the obs-dmarc-uri route, imitating how RFC 5322 does it.
obs-dmarc-uri = dmarc-uri [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; Obsolete syntax, reporters should ignore the
; size if it is found in a DMARC Policy Record.
and then update dmarc-urilist with the alternative
dmarc-urilist = ( dmarc-uri *(*WSP "," *WSP dmarc-uri) )
/ ( obs-dmarc-uri *(*WSP "," *WSP obs-dmarc-uri) )
Seems OK to me.
+1.
Best
Ale
--
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org