On 11/17/25 20:20, Murray S. Kucherawy wrote: > On Mon, Nov 17, 2025 at 11:27 AM Daniel K. <[email protected]> wrote: > >>> At this point I don't think the validity of an unencoded '+' is >>> disputed. The problem seems to be that the consumer of the DMARC record >>> does not do any pct-decoding at all, leading to the misdirected reports. >> >> Or, reading over and thinking about it again, maybe the consumer is just >> being selective about what to decode, since '%' itself is in 'atext'. >> > > I think "+" as part of an email address, when used in a "mailto" URI, must > be encoded because it's a reserved character in both RFC 3986 and RFC > 6068.
I'm not so sure. Per RFC 3986, [email protected] is a path, and quoting the relevant ABNF from that document: path includes path-rootless as an alternative path-rootless = segment-nz *( "/" segment ) segment-nz = 1*pchar pchar = unreserved / pct-encoded / sub-delims / ":" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" As sub-delims is different from pct-encoded, I conclude that '+' must not necessarily be pct-encoded. > Interoperability, then, is only guaranteed when all consumers do the > decoding. Agreed, any char *could* be pct-encoded, not just the chars outside of unreserved, reserved, etc. and the implementation should be prepared to encounter and handle, e.g. %6c%6f%63%61%6c%2b%70%61%[email protected] just as well as the more human readable version at the start of my reply. Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
