On 11/17/25 15:48, Todd Herr wrote:
> On Mon, Nov 17, 2025 at 9:46 AM Marc van der Wal wrote:
>>
>> [...]
>>
>> 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.
Also, RFC 6068, defining the 'mailto' URI scheme, says this:
local-part = dot-atom-text / quoted-string
referring to RFC 5322 for the definition, which includes '+'.
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
dot-atom-text = 1*atext *("." 1*atext)
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.
Daniel K.
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
