On 1/19/2021 2:22 PM, Todd Herr wrote:
I'm sorry, but I'm not clear on what position you're advocating here.
You assert that "any problem would be a known tag with new
functionality than originally expected" (which would seem to argue for
using a new tag such as ruap) but then you state that you're for a URI
protocol method as part of the current tag (which would seem to argue
against using ruap, but instead figuring out a way to add https: to
rua), but then you state you don't see any issue with adding new tags.
Can you help me understand your position better, please?
Yes, I saw. Allow me to clarify. Diffs in tags vs diffs in tag values.
Overall, I think we should not be "afraid" to invent use new tags.
This is the main consideration I was pointing out. Implementation
MUST not fail with unknown tags.
However, with a known tag, in this case the reporting mechanism, I can
see now the only delivery protocol defined was "mailto:";
I don't think we can add a "https:" here without probably causing some
issue with some existing implementations, i.e. report generated by the
assumed email address will fail (no delivery). But we don't know for
sure. An implementation may not fail if its checking for the
"mailto:"; prefix. Reports would be skipped if HTTPS is not supported
by the verifier.
I think we should add/defined the "https:" for the exist reporting tag
ABNFs. The only one who will understand it are implementations with
HTTPS delivery support only. Others will simply not be able to send a
report to a domain that desires HTTPS delivery.
I think the worst that will happen is a non-https implementation will
have one of the following:
1 - check for the prefix "mailto:"; and extract the address at 6 position
2 - not check, assume plus 6 has the a valid address.
In each case, it will fail (no https delivery supported), #2 may be an
a wasted delivery attempt to an invalid email address.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
