On Mon, Nov 17, 2025 at 9:46 AM Marc van der Wal <marc.vanderwal= [email protected]> wrote:
> Hi all, > > A colleague of mine is setting up DMARC on his domain and would like to > receive aggregated reports on an e-mail address that looks like > <[email protected]>. Because of that, he stumbled upon an > inconsistency in implementations of DMARC at the recipients’ ends, and > I’m trying to figure out which implementations are correct or incorrect > with respect to the parsing of mailto URIs in rua/ruf tags. > > Reading RFC 7489, and noticing that the argument for a rua tag is a > DMARC URI, he assumed that the + sign had to be percent-encoded, leading > him to set up his DMARC like this: > rua=mailto:me%[email protected]. > > To his surprise, he noticed that some ESPs send the reports to > me%[email protected] (not percent-decoding the + sign), while > others send the reports to [email protected], meaning that > they did percent-decode the + character. > > Hence my question: who is right? All "!", "," and ";" characters > appearing in e-mail address local-parts must be encoded, that is clear > enough from RFC 7489. But what about the other characters listed in > gen-delims or sub-delims in RFC 3986? Must these characters be > percent-encoded in ruf/rua tags, or must they stay unencoded? > > RFC 3986 is not an area of expertise for me, but as I read section 2.2 in that document, I see this as the last paragraph: URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII. Further on, in section 3.2.1, I see this: userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) and with sub-delims defined like so: sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" and RFC 7489 and DMARCbis not specifically calling out "+" as a character to be encoded, it seems to me that since the "+" is allowed in the userinfo component, then it should not be encoded. At least, that's how I'd read RFC 3986. However, I'll let others with much more expertise weigh in on the matter. -- Todd
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
