I don't think that's what they were saying. The issue in that thread was that the address format was "foo@example.org <foo@example.org>", where the e-mail address itself is set in the first part rather than a name.

If I'm reading the ​RFC 2822 correctly, the Reply-To header can accept an address-list just like a To or From header, so an entry like "Jane Doe <jane@example.org>" is perfectly acceptable.

I'm not sure where the "@macenzie.local" part is coming from. Obviously it's your actual test installation, but what I mean is that I'm not sure how it's being added to the Reply-To header, directly after the encoded-word part of the header.

Are you testing with latest trunk? PHPMailer was updated recently to 5.2.7 (see #25560). When I test with latest trunk with this update, here are the verbatim headers that are generated:

I'm not sure where the "@macenzie.local" part is coming from. Obviously it's your actual test installation, but what I mean is that I'm not sure how it's being added to the Reply-To header, directly after the encoded-word part of the header.

Yeah, that made me curious too. macenzie.local is the local hostname of the server, rather than the domain name of the virtual host. I've traced the headers from wp_mail() through PHPMailer to mail() and they look fine the entire time, even though they're malformed in the message I actually receive.

That looks correct to me, but so far I haven't been able to find an RFC or anything that specifies what the format should be.

​RFC 2047 describes UTF-8 encoded headers (also see #18521). As far as I can see, encoded-words are allowed in To, From, CC, BCC (and thus likely Reply-To headers). Although, looking through here again, it does mention that "An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'." I think this means that instead of this:

Reply-To: =?UTF-8?Q?Luk=C3=A1=C5=A1_LastName_<foo@example.org>?=

It's possible that it's *supposed* to be:

Reply-To: =?UTF-8?Q?Luk=C3=A1=C5=A1_LastName?= <foo@example.org>

In other words, I think it's possible that the actual email address is supposed to never be included in an encoded-word section.

This would certainly mean it's a bug in PHPMailer upstream then if that's correct.

I think I'm right about that last comment. This isn't a bug in PHPMailer. PHPMailer defines a function specifically for this purpose rather than adding it as a custom header, see $phpmailer->addReplyTo(). Addresses added in that manner are encoded correctly. So if I use this instead:

So... I'm just going to suggest a close as invalid since it is possible to still make this work in 3rd party code. Here's one kind of weird way to do it anyway, but this is assuming you don't want to plug in you're own custom wp_mail() function:

If someone wants to expand core wp_mail() to detect 'Reply-To' headers, and automatically do this itself, that might be nice, but it seems like this isn't so much a "bug" as it is intentional behavior.

It seems like a bug to me, since Core is using AddCustomHeader() instead the appropriate method, and that causes an undesirable result. I think plugin authors have a reasonable expectation that they can add a Reply-To header without any extra fuss.

I don't see any drawback to making wp_mail() use AddReplyTo(), and if we do that then it would "just work" for everybody. If we don't, then any plugin dev who wants to set a Reply-To will potentially get bit by this; and if they do, then they'll have to spend a lot of time figuring out what happened and how to work around it.

I attached a first attempt at a patch in case others think it'd be a positive change.

The address methods like AddAddress() and AddReplyTo() do some filtering on the addresses to make sure that they're compliant with the RFCs, but AddCustomHeader() doesn't because it rightfully assumes that the appropriate methods will be called when dealing with headers containing addresses.

So, there are potentially other problems being caused by using AddCustomHeader() instead of AddReplyTo(). Any fatal errors that would be corrected by the filtering in AddReplyTo() are currently failing.

Yeah, the patches I added are essentially the same thing, but they're a little bit cleaner IMO since they loop through the three header types and run the same block of code, rather than duplicating it multiple times. You should get props for the original patch, though.

I also refactored a few things to keep the function DRY, but I'm happy to back that out if it feels like too much.

I also went ahead and updated wp_mail() to use $phpmailer->setFrom(), rather than accessing the object members directly. I think that's argubably within the scope of the ticket, since the underlying bug here is that wp_mail() is treating addresses as if they're generic strings. In reality, they require special handling, and using the methods PHPMailer provides will run them through the appropriate processing and avoid other potential bugs. I'm happy to remove that from the patch too, though, if it seems like too much.

It looks good: it fixes the bug, passes the tests and removes some duplicate code. My only concern is that using variable variables is slightly cryptic and difficult to follow. Could to, cc , bcc and reply_to be keys in an array rather than variable names, avoiding the need for$$address_header?

Additionally my personal preference would be to use an explicit switch statement rather than $header_method_map and call_user_func - it's slightly more lines, but it reads a little more easily:

Previously, wp_mail() implemented Reply-To as a generic header, using
PHPMailer's addCustomHeader(). As such, the email address portion of
the header was being incorrectly encoded when the name portion
contained UTF-8 characters. Switching to PHPMailer's more specificaddReplyTo() method fixes the issue.

For greater readability, the handling of all address-related headers
(To, CC, BCC, Reply-To) has been standardized.