PHPMailer::punyencodeAddress wrong ?

[tnbnicer]

Hi. I have been playing around a little with non-ascii character addresses. 'Playing' is to be taken literally, because with such an address, it is difficult to test. My server however does return mail delivery failure messages.
In this case, let us say, the intended recipient is ice@bücher.de. Converted as follows -> $email=$mail->punyencodeAddress($email);
The message goes out and the server sends me a mail delivery failure message. It says, ice@xn--b14cher-xwa2143e.de (the punycode) is an unrouteable address.
Shouldn’t ice@bücher.de be converted to this instead: ice@xn--bcher-kva.de. Maybe my server is goofing it up in the mail delivery failure message. Or maybe ice@xn--b14cher-xwa2143e.de is correct? Without knowing the answer that, I do not wish to implement PHPMailer::punyencodeAddress in an online form. If someone does have a non-ascii character email address which they use in the form to get a reply, it might be wrong.
Is ice@xn--b14cher-xwa2143e.de the correct conversion of ice@bücher.de?

[tnbnicer]

Partial solution -> $email=$mail->punyencodeAddress(mb_convert_encoding($email, 'ISO-8859-9', 'UTF-8'));
By converting to ISO-8859-9 first punyencodeAddress indeed correctly outputs ice@xn--bcher-kva.de.
That would work for French and German. Chinese is another matter: info@网站.亚洲

Another way ->

if ($mail->has8bitChars($email)) {
$puny=explode('@', $email, 2);
$ynup=explode('.', strrev($puny[1]), 2);
$email=idn_to_ascii($puny[0]).'@'.idn_to_ascii(strrev($ynup[1])).'.'.idn_to_ascii(strrev($ynup[0]));
}

$mail->has8bitChars($email) in the first line is PHPMailer syntax.
The rest is pure PHP.
explode()
strrev()
idn_to_ascii()

It seems to work with Chinese.
info@网站.亚洲 -> info@xn--5tzm5g.xn--jlqt95e
And Greek.
δοκιμή@παράδειγμα.δοκιμή -> xn--jxalpdlp@xn--hxajbheg2az3al.xn--jxalpdlp
myemail@όνομα.gr -> myemail@xn--mxavci7d.gr
Not to mention German and French.
myimpossibleemail@bücher.de -> myimpossibleemail@xn--bcher-kva.de

It seems to work. It has not been tested with real recipients. So, if anyone sees a fatal flaw, ...

[Synchro]

It's because you have not set the CharSet as the code suggests.

PHPMailer defaults to ISO-8859-1 (because we can't assume that ext-mbstring is available), but here you are passing in a UTF-8 string (because your source code is UTF-8):

$mail = new PHPMailer();
$a = $mail->punyencodeAddress('ice@bücher.de');
var_dump($a);
//Result:
ice@xn--b14cher-xwa2143e.de

Now with CharSet set, the charset matches, and thus the encoding can work correctly:

$mail = new PHPMailer();
$mail->CharSet = 'UTF-8';
$a = $mail->punyencodeAddress('ice@bücher.de');
var_dump($a);
//Result:
ice@xn--bcher-kva.de

[tnbnicer]

You are right.

$mail->CharSet = 'UTF-8';
$email=$mail->punyencodeAddress($email);

French, German, Chinese, Greek — all fixed.

You might be right, and I might be shooting myself in the foot, almost, ...

For δοκιμή@παράδειγμα.δοκιμή

Error: δοκιμή@xn--hxajbheg2az3al.xn--jxalpdlp does not appear to be a valid email address.

Whereas, using my method, xn--jxalpdlp@xn--hxajbheg2az3al.xn--jxalpdlp is valid.

Another point I ought to mention is the automated reply message sent as HTML.

if ($mail->has8bitChars($name)) {
	$charset = "utf-8";
	$encoding = 'quoted-printable';
	$convmap = array(0x80, 0x10ffff, 0, 0xffffff);
	$htmlname = mb_encode_numericentity($name, $convmap, "UTF-8");
} else {
	$charset = "us-ascii";
	$encoding = 'quoted-printable';
	$htmlname = $name;
}

The form user will receive an email in response. If the user’s name is Günter, the reply going out changes u-umlaut to .

Dear Gnter, thanks for your order.

And so on.

Character set is determined by whether the recipient is named Günter or not, but otherwise, I take it all back. When the character set is 'utf-8', PHPMailer::punyencodeAddress works fine.

I don't quite agree that the case is resolved. There is more to be said on the subject of public function punyencodeAddress($address).

        **if (defined('INTL_IDNA_VARIANT_UTS46')) {
            //Use the current punycode standard (appeared in PHP 7.2)
            $punycode = idn_to_ascii(
                $domain,
                \IDNA_DEFAULT | \IDNA_USE_STD3_RULES | \IDNA_CHECK_BIDI |
                    \IDNA_CHECK_CONTEXTJ | \IDNA_NONTRANSITIONAL_TO_ASCII,
                \INTL_IDNA_VARIANT_UTS46
            );**

I do not claim to know what all those standards imply, but the developers might want to take a closer look at why in particular the part of an email address before the @ is left as-is, while domain and tld are converted.

[Synchro]

No, xn--jxalpdlp@xn--hxajbheg2az3al.xn--jxalpdlp is not usable, and you might want to take a closer look at RFC3492 before casting aspersions on the developers. The clue is in the name: IDNA stands for "Internationalised Domain Names in Applications", note Domain Names, not email addresses, and as a consequence, it does not apply to the local part. See my answer to #3250.

It's bizarre that you would be surprised that your output contains numeric entities when you're the one calling mb_encode_numericentity that creates them. If you use HTML entities outside a raw HTML context (e.g. in a plain-text body), it's not going to render entities into Unicode characters and you will get the result you are seeing. There is no plain-text equivalent of HTML entities; you must use a character set that includes the characters you want. The quoted-printable transfer encoding will work, but you're preventing it from doing so by converting the characters it would encode before it gets a chance to work. Just don't do that.