Levél tárgyból etűnő ékezetek. ki a hibás?

Fórumok

Sziasztok!

postfix+cyrus páros próbálgatom.

Vajon melyik cseréli le a levelek tárgyában az ékezetes betűket X -re?
Thunderbird-el megnézve a levelet X van az ékezetek helyén.
Megnézem a levelet a kiszolgálón is a cyrus könyvtárában és ott is X-el tárolódnak a levelek.

Kerestem a fentiekre karakter kódolás beállítását, de nem találtam megoldást.

Hozzászólások

A level kuldoje a hibas, aki elfelejtette megemliteni a subjectnel hogy milyen kodolast alkalmaz.

---
Apple iMac 20"
áéíóöőúüű

nekem két szerveren van postfix+cyrus, és mindkettőt legújabb 2-es thunderbird-del használom windows alól, és az egyik szervernél xX-re cseréli az ő és ű betűket, a másiknál meg nem. szóval nem a kliens hibája ez. az egyik szerveren régebbi (nemtudomhányasverziójú, ami ubuntu 7.04-es default verzsön) postfix+cyrus fut, a másikon meg újabb, (ubuntu 8.04.3 defaultverzsön), és találd ki, melyik nem cseszi el az ékezeteket? :) igen, az újabb verzsön.
egyébként azt kéne első körben megnézni, hogy küldesz hálón belül a saját postfixednek egy emailt, ami cyrus-ban landol, és megnézed, hogy akkor is elcseszi-e. ha igen, akkor nem a fetchmail a ludas.

----------------------------------
feel the beat - it's everywhere!

[off]

Tényleg van ilyen kapcsoló? Vagy ez csak egy feltevés...

Mondjuk az a konfig opció neve, hogy "intentionally_mess_up_accents_in_the_subject", és a default true-t kell false-ra állítani... Vagy még inkább egy "shall_this_software_work_correctly" opció...?

Az összes olyan fejlesztőt, aki megírja szoftverét úgy hogy az tudjon helyesen és hibásan is működni, és ezt a döntést a felhasználóra vagy rendszergazdára bízza, úgy tökön kéne szúrni hogy életében ne akarjon még egyszer billentyűzetet venni a kezébe.

[/off]

Adj egy accountot a szerverre, megnézem.

ad1. Nem X-el tárolódnak a levelek, hanem X-szel.

ad2. Kísérd végig a levelet útján és nézd meg a nyers (mailbox) formátumot minden alkalommal, amit áthalad a hálón, egyik progi átadja a másiknak. Az itt látott adatot vesd össze az smtp és társai specifikációjával, hogy meg tudd állapítani, melyik lépésben valójában milyen ékezetes betűket kódol a levél.

Ha nincs a fejlécek között egy Mime-Version: 1.0 sor, akkor a levél hibás. Ékezetes fejlécmező használata esetén ez a mező kötelező.

Ha a Subject: sorban szerepel 127-nél nagyobb byte (vagyis tetszőleges ékezetes betű bármilyen karakterkészlet szerint), akkor a levél hibás. Ékezetes betűt muszáj ilyen -=Q=..=- típusú mágia közé rakni (bocsánat, totál nem emlékszem a szintaxisra).

Ha még nem vérzett el a levél, akkor komoly esély van rá, hogy helyesen kódolja az ékezetet (persze még ekkor sem biztos). Az -=Q..=- vagy -=B..=- részt kódold ki: először állíts elő egy nyers bytesorozatot, B esetén base64 dekódolva a sztringet, Q esetén pedig az =XX értékeket hexaként értelmezve. Majd a kapott bytesorozatot jelenítsd meg, mindenképpen az ott megnevezett karakterkódolás szerint (vagy nézd ki egyenként az értékeket karaktertáblából). Ha ez stimmel, akkor a levél jó.

Cyrus lesz a bűnös.

Ha konzolról küldök levelet akkor X-re cseréli az ékezeteket és ebben az esetben a fetchmail nem nyúl hozzá.
Korábban Exim volt Postfix helyett és akkor is ez volt a helyzet.

Szóval Cyrus. Debian etch-en. Lehet, hogy forgatnom kellene egy újat? nem akarom :(

További 5let?

Sajna account-ot nem tudok adni. De szívesen megmutatok itt minden configot.

igazából nem bűnös a cyrus. ahogy fent is írták, valami RFC szabvány szerint nem lehetnek 8 bites karakterek a tárgyban, ezeket 7bitre kell kódolnia a _kliensnek_ küldéskor. az, hogy néhány kliens ezt leszarja, az nem a cyrus hibája.
nem nagyon ismerem a szerver oldalon futó filtereket, de talán esetleg lehetne rá írni egy bc szabályt, ami kicserélgeti a 8bites karaktereket a megfelelően kódolt karaktersorozatra a tárgyban és úgy rkja a postafiókba.

----------------------------------
feel the beat - it's everywhere!