Geeklog Forums

Have modified COM_mail in order to facilitate mail sending with Chinese header lines (subject, to, from) for my GL site. Some mail servers doesn't handle non-ASCII and corrupt the mail header. Not sure whether COM_mail is the right place but it solves my problem at the moment. Hope that it can be incorporated in GL somewhere in the next revision...

if( empty( $from ))
{
$from = COM_formatEmailAddress( $_CONF['site_name'], $_CONF['site_mail']);
}

-----------codes-added-after-above-statement-------------
$lt_pos = strrpos($to, "<"
if ($lt_pos > 0)
{
$to = '=?' . $charset . '?B?' . base64_encode(substr($to, 0, $lt_pos)) .
'?= ' . substr($to, $lt_pos);
}

$lt_pos = strrpos($from, "<"
if ($lt_pos > 0)
{
$from = '=?' . $charset . '?B?' . base64_encode(substr($from, 0, $lt_pos)) .
'?= ' . substr($from, $lt_pos);
}

$subject = '=?' . $charset . '?B?' . base64_encode($subject) . '?=';

----------------------------------------

Cheers.

I've submitted a patch a while ago about this (in the currently dead project site) so com_mail would use iconv_mime_encode to deal with those headers you mentioned (when in UTF-8 mode).

Although my problem was that the receiver sees Gibberish, I guess it helps you too.

We have the same problem then. Your description of the problem is better. It's not really the whole header is corrupted but receiver sees gibberish.

However, iconv_mime_encode is for PHP5 as highlighted in your post. My webhoster is still running on PHP4. Is it possible to merge in a PHP4 solution also?

Give your host a wakeup call. My host lets me decide if I want v4 or v5.

The most annoying concept for a programmer is to be forced to come up with a solution for an already solved problem...

I can only suggest you look for pages (especially on php.net) that give ideas how to simulate that function in v4.

It's ok. I can do the PHP4 work myself. Actually, my clip above is what currently runs on my version of lib-common.php. It's not as perfect as iconv_mime_encode (which does also line overflow handling) but sufficient in most cases.

Just that I am wondering whether that piece of code can also get into the official version of GL (say, if PHP5, do iconv_mime_encode, else do base64_encode, etc.) so that I don't need to worry about a code merge per every GL upgrade...

Cheers.

When the project site is back, just add your solution to the patch under an "else" clause (my first "if" is the v5 check).

Then again, my solution also checks for UTF-8 mode in order to work.

I guess once the project site is up, I'd make it a single "if" for both checks to make your addition easier.

Thanks.

The project site is back (hooray!).

I've coded your version and attached it there. Would you be willing to test it?

Sure... but where's the attachment?

Consider this a "find the treasure map" game as the tracker's links are too dynamic for direct links.

Click the "Report a Bug" in the side menu.
Then in the new site click "Geeklog 1".
Then "Patches"
Find and click "Support for UTF-8 e-mail headers".
X, ah, I mean "Attached Files" mark the spot.
Download the newest experimental version.

Oops, a real fun... Got the patch and will keep you posted of the results.
Cheers.

Ah... too bad, just tested one day before the official release of GL 1.4... It had been busy weeks for me and thus the late response... Sorry.

Anyway, have tested the Extended Version (experimental) patch on GL 1.3.11sr3 (my site) and it works like charm. Many thanks.

The test is pretty extensive by using the mail-article as well as email-to-user GL pages to ensure that all TO, FROM and SUBJECT lines are tested, both with pure English and Chinese, and mixed English/Chinese. All passed!

Cheers.