Suggestion and Contribution of OUTGOING_CHARSET

SqWebMail has an ability to handle multiple character set (charset)
like utf-8, iso-2022-jp, iso-8859-01, and so on.
The charset is specified in html template directory CHARSET file.
The charset is used to send data with Web browser and SMTP server.

I use sqwebmail in japanese with japanese patch which I developed.
In Japan, iso-2022-jp is widely used as e-mail contents charset.
Iso-2022-jp is shift-in and shift-out style 7bit encoding.
The japanese patch assumes CHARSET is iso-2022-jp,
and do some iso-2022-jp specific fix,
so I think that merging with main source is hard.

To use SqWebMail in other languages (at least in japanese),
I suggest to enhance current SqWebMail charset capability.
Practically, I suggest to separate the Web browser charset and
e-mail content charset to send.
CHARSET specifies Web browser charset like until now, and
OUTGOING_CHARSET specifies outgoing e-mail content charset.

Then, In japanese environment,
I can set CHARSET=utf-8 and OUTGOING_CHARSET=iso-2022-jp.
Utf-8 (generally, 8bit non-shift-in-out sytle coding) is preferred
to handle strings inside SqWebMail,
Iso-2022-jp is preferred to be received
by many poor terminals including celler phone.
Of course, when CHARSET is same as OUTGOING_CHARSET,
the behavior is same as now.

I have developed such patch and attach it in this mail.
I developed it under 3.6.0. (Time flies during I straggled)
I hope this concept will be merged into main source tree.

I found some modification between 3.6.0 and 3.6.2 corrupt with my patch.
rfc2047_print_unicode() and header_wrap() are similar works, and
I think it's possible to integrate these works.

And my patch includes some rfc2047 compliance bug fix.

toshi

-- 
Toshikazu Ichikawa <[email protected]>
Site: http://www.toshikazu.org/ (including my PGP public key)
Key fingerprint = 1C98 7233 F225 D783 0A70  A958 2876 F825 F0CD 25EA