Amióta először feltelepítettem az Exchange 2003-at, azóta tapasztalok egy igen ronda hibát. Néha - akkor még úgy gondoltam meghatározhatatlan, hogy mikor - jönnek olyan levelek, amikben a magyar ékezetes karakterek helyett helyes kis kínai írásjelek találhatók. Akkoriban az elsőszámú gyanúsítottam a Lotus Notes volt, miután a hibás levelek tipikusan Notes kiszolgálókról érkeztek. Még a korai időszakban rájöttem, hogy valahogy, valamiért, valahol, valaki a kelet-európai kódkészletet utf-8-nak ismeri fel.
A problémára megoldás nem volt, csak meg lehetett kerülni azzal, hogy azon a levélen, ami ilyen jeleket mutatott, átállítottuk a kódkészletet utf-8-ról kelet-európaira és elmentettük.
Ez a "megoldás" ugyanakkor fapados, ronda és kényelmetlen.
Időközben eltelt egy-két év és sajnos a fent említett jelenség elkezdett szaporodni. Miért? Az ok: gmail. Sajnálatosan megfigyelhető, hogy a gmail-ről érkező magyar ékezetes levelek legnagyobb százaléka a Notes-al megegyező tüneteket produkál.
A levelező listákon, fórumokon egyre többször előkerül a probléma.
Két napja megelégeltem az ügyet és úgy döntöttem, a végére járok.
Mintegy másfél napnyi nyomozás (kb. 100 db levél elküldése) után a következőkre jutottam:
A hibás levelek a fejléc mezők és a levéltörzs kódolásának eltéréséből adódnak.
Hogy is néz ki ez?
Ha egy levél feladó, címzett vagy tárgy mezejébe a 7 bit-es karakterkészlet feletti karakter kerül (pl. magyar ékezetes), akkor ezt a rendszer átkódolja egy speciális formátumba és ebben a formátumban megjelenik az eredeti szöveg kódkészlete is. Ugyanez vonatkozik az üzenetre is. Ezeknek a kódkészleteknek elvileg nem kell megegyezniük (nem néztem meg az RFC-t, de valami ilyesmi rémlik).
Ha az Exchange kap egy levelet amiben két ilyen kódolás eltér (pl. van egy gmail accountunk, ahol a nevünk ékezeteket tartalmaz, akkor abból iso-8859-1 -es kódolás lesz, ugyanakkor, ha magyar ékezetes szöveget írunk a levéltörzsbe, akkor abból iso-8859-2 lesz - mondjuk fogalmam sincs miért ), akkor megpróbálja közös nevezőre hozni a levelet (vajon minek?). A közös nevező pedig az utf-8 lesz. Ez eddig rendben is lenne, de a levélkódolását átkapcsolja ugyan utf-8 -ra, de nem kódolja újra és ebből lesz az a kínai csoda, amit kapunk (ááááá most jöttem rá miért! Szoktatni kell a jónépet az eljövendő kínai világuralomra! ).
Mostmár tudjuk, hogy mi történik, de hogyan tudjuk ezt kijavítani?

A Microsoft készített egy hibajavítást erre a problémára ami innen beszerezhető. A dolog szépséghibája, hogy többek szerint (én nem próbáltam) nem működik. Sajnos (szerencsére) még mielőtt rátaláltam volna erre a javításra saját magam írtam egy SMTP EventSink-et ami nálam bevállt, és mások szerint is működik.

A dolog működése nagy vonalakban a következő:
1. A bejövő levél minden fejlécmezejéből kivadásszuk a kódkészletre vonatkozó bejegyzéseket.
2. Egyesével összehasonlítjuk ezeket a bejegyzéseket a levéltörzs kódolásával
3. Ha bárhol eltérést tapasztalunk akkor a levéltörzset átkódoljuk utf-8 -ra.

A megoldás programkód itt található.

A telepítéshez a következőkre van szükségünk:
1. Be kell szereznünk az SMTPREG.VBS fájlt. Ezt megtaláljuk a Microsoftnál, vagy itt.
2. Tegyük be az SMTPREG.VBS-t és a CorrectCharsets.js fájlt egy könyvtárba pl. c:\Sinks
3. Vegyünk elő egy parancssort és lépjünk be a 2.-es pontban létrehozott könyvtárba.
4. Futtassuk le a következő két parancsot:

cscript smtpreg.vbs /add 1 OnArrival CorrectCharsets CDO.SS_SMTPOnArrivalSink "mail from=*"
cscript smtpreg.vbs /setprop 1 OnArrival CorrectCharsets Sink ScriptName "c:\Sinks\CorrectCharsets.js"