idn support

It would be nice if this class had International domain name support using punycode. http://en.wikipedia.org/wiki/Internationalized_domain_name

This could be solved by running all email addresses through something like

public static function idn_convert($email, $charset) {
if ($email === null) {
return null;
}

preg_match('/^([^@]+)@([^@]+)$/', $email, $matches) || die("error");
$local_part = $matches[1];
$idn_utf8 = iconv($charset, "UTF-8", $matches[2]);

//idn_to_ascii from packages php5-idn.deb, until we use php 5.3 and http://dk2.php.net/manual/en/function.idn-to-ascii.php
$escaped_email = sprintf("%s@%s",
$local_part,
idn_to_ascii($idn_utf8, "UTF-8")
);
return $escaped_email;
}

Inside functions like SetEncodedEmailHeader() and SetMultipleEncodedEmailHeader().

As far as I know the class does not stop you from using e-mail addresses with domains encoded the way you need as it does not validate the e-mail addresses you pass it.

I am not sure if you are saying
1) I can just encode the email addresses myself before passing them, and the class will accept the punycode-encoded version (I am doing this in my own use of mimemessage).
or
2) The mimemessage class will accept unicode-encoded email addresses

in case of 1) then it is obvious, since punycode is designed to be pure ASCII.

In case of 2), then mimemessage may accept unicode, but some mail systems along the email's path may not. So you always want to punycode-encode the idn, as I understand it.

My point is that the proper encoding of the idn email address is a technical detail of the email format. IMO such technical details are best encapsulated inside the mimemessage class. The whole point of the mimemessage class is to encapsulate technical details :).

No, the MIME standard does not define that you should encode e-mail addresses in special way. It just defines that that if you need to pass 8 bit data in headers, they should be encoded with q-encoding to turn then into ASCII characters only for transmission.

The class takes care of this. It is not relevant whether the e-mail addresses are in puny code or not.

You just need to pass the e-mail addresses and tell which character set you are using for the bytes you are passing to the class: iso-8859-1, utf-8, etc..

At least older versions of the RFCs specify that the email address should be ASCII only. So systems which stricly implement this will choke on IDNs in unicode.

To ensure maximum compatibility, always encoding the idn in punycode is The Right Thing To Do, as far as I can tell.

One example of an email system which only accepts punycode-encoded idns, and not unicode-encoded idns, is mimemessage's very own email validation regexp.

I am afraid you are confusing the issues.

As I mentioned above, the class already encodes headers that contain 8 bit characters as q-encoding. It does not matter if the e-mail addresses have puny code or not.

E-mail address validation has nothing to do with e-mail composition because the class does not validate the e-mail addresses you pass it when the messages are delivered.

Before assuming that the class does not work, try sending the message as I told you before, passing the address encoded with puny code or not and specify the correct character set encoding.

Actually it is you who are confused. See the SetEncodedEmailHeader() function from email_message.php :

Function SetEncodedEmailHeader($header,$address,$name)
{
return($this->SetHeader($header,$this->QuotedPrintableEncode($name,$this->default_charset).' <'.$address.'>'));
}

Only the $name is encoded, not the $address which contains the IDN.

There is no confusion on my part.

I just told you several times that the class intentionally does not encode or validate e-mail addresses when sending messages.

You are the one that is assuming that the class does something that it doesn't do.

I specifically said that the class did NOT currently encode the email address. What I am saying is that I think that it should be changed to encode the email address in punycode.

What I am trying to tell you is that the class does not do that on purpose and will not do it because it adds a lot more complexity to implement a feature that very few people need.

On the other hand you can encode the addresses if you need that and pass to the class. If you do not know how to do it, there is a class specialized on that here:

phpclasses.org/idna_convert