Hülye email

Csak egy kis morgolódás, amiért valaki kitalálta annó, hogy a plaintext emailek szövege legyen 72 karakternél tördelve küldéskor, és mégegy ráadás azért, mert a mai napig megmaradt ez az ódivatú, és messze nem praktikus gyakorlat.

Az apropója ennek a bejegyzésnek az, hogy épp most tördeltem újra egy többoldalas szöveget, amit e-mailben kaptam, és ki kellett raknom valahova egy bejegyzésként. Ahelyett, hogy egy egyszerű másolás-beillesztéssel megoldottam volna kénytelen voltam a küldő email kliense által önkényesen bepakolt sortöréseket egyesével kitörölni.

Furcsa számomra, hogy ennyi év és tapasztalat után sincsenek ilyen apróságok helyreigazítva. Az is furcsa, hogy a html email a mai napig miért nincs felhozva az "élő szabvány" szintjére.

No mindegy, csak ki akartam panaszkodni maagam :)

( bucko | 2016. 06. 14., k – 12:22 )

A küldő email kliense beállítható, hogy ilyet ne tegyen.
"Adatot" meg mindig csatolmányként, tömörítve.
Ha mégse, akkor egy sor sed.
stb.

Ez nem szabvány, inkább trehányság.

Igaz, ezért ideidézem magamtól amit feljebb írtam: "Persze mindez kódolástól és egyéb formázástól is függhet."
A példa a quoted literal formátumra vonatkozik.

Komolyan mondom, hogy a mail bármit tartalmazhat! Nem túl régen játszadoztam egyet.
Adott 2.015.000 file egy (mail és még sokminden) szerveren. Megállapítandó, hogy melyek mail-ek, hányszorosan duplikáltak, mi lenne a nevük és kinek az in- vagy outboxába kellene lenniük. Előtte/utána a dir-eket is hasonlóan átpofozni. Ehhez először fixálni kellett a huszonX kódkészletből származó fileneveket, hogy biztonságosan feldolgozható legyen. (Előzmények: A raid csatoló kissé dadogós lett. Kürt barátunk - alig 500 kilóért - az összes linux filesystemet felrakta 1db unicode/hu ntfs-re. Mert nem mondta nekik senki, hogy ez marhaság. :))))
Az eddig offnak tűnő dolog itt csörgedezik tovább. :)
Szóval alkalmam nyílt kb. 850.000 mail headerbe belepillantani. Szinte hihetetlen, hogy ezek bárhová eljutottak! Az iso8859-1 kódolásúnak hazudott iso8859-2 szerű quoted printable cp852 kódolású nevek a From vagy a To mezőben apróságak tűnhet a rosszul elválasztott és rosszul tört címekhez képest. Mindezt sokszor az eltérő kódkészletek, kliensek és az egér okozza. Hát még a továbbított levelek!
Visszakanyarodunk.
Hasonló a kavalkád a body esetén. A mail kliensen be van állítva kódkészlet, a formátum stb. Ebbe bele kell húzni egy word dokumentumból, meg egy-két más kódolású és nyelvű weboldalról néhány darabkát. A kliens felismer(heti) a kavarodást és figyelmeztet. Vagy nem. Aztán a fogadó kliens kicsit másképp értelmezi, beleírsz, továbbítod, és a hatás rosszabb esetben leírhatatlan.

A rövid válasz: Univerzális filtert nem igazán lehet írni, vagy csak sok munkával. Ötletesen, rekurzívan hívogatni az erre szakosodott libeket lehet egészen addig, amíg nincs hiba (a mailben és/vagy a libben). Egy-egy mail esetén némi gyakorlattal akár ránézésre is orvosolható a hiba. Persze ez feltételezi, hogy aki ránéz, az látott már ilyet. ;)

Abszolút off: A minap egy haver kérdezte milyen néven hupolok, én vagyok-e a locsemege? :D

ha a paragrafusok közt nincs üres sor, akkor milyen paragrafusokról beszélünk?
ha a szövegben - legyen bárhogy tördelve - nem elkülöníthatő a paragrafus, akkor vagy minden sor egy paragrafus, vagy nincs egy paragrafus sem: mindkét esetben gyakorlatilag nincs paragrafus.
ha már elkülöníthetőek "\n\n", vagy "\n[\x20\x09]+"-ek, akkor ezek alapján újra lehet formázni.

ezen kívül egyetértek az eredeti felvetéssel, hogy bajosan lehet email body-ban richtext-et veszteségmentesen átvinni.
ezt én a másik irányba szorgalmazom megoldani: body-ban csak plain text lehet, formázott cucc menjen csatolmányba.
egyetértek továbbá az elégtelenkedéssel, ami a userinput önkényes tördelésére vonatkozik.
tördelje a mailer progi, de csak az enkódolt adatot! az én inputomat őrizze meg annyi CRLF-vel, amennyit begépeltem.
ebben az ügyben sztem ott van a kutya elásva. hogy egyik v másik mailer nem veszi szigorúan a Content-Transfer-Encoding -ban kijelentett enkódolást.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

"ha a paragrafusok közt nincs üres sor, akkor milyen paragrafusokról beszélünk?"

Akkor ne paragrafusokról beszéljünk, hanem csak sima szándékolt sortörésekről. Mondjuk egy vers sorairól. Vagy egy programkódról. Vagy egy felsorolásról. Nem mint ha verseket kapnék e-mailben. De ettől függetlenül nem tudom hogy lehetne különbséget tenni aközött, hogy egy sortörés szándékolt a küldő által, vagy csak a hosszú sorok tördelése miatt került bele automatikusan.

Ha én írok valamit, akkor kihagyok egy sort két bekezdés közt. Más viszont nem teszi (mint ahogy a tegnapi példa is mutatja) és ezzel is kell tudni kezdeni valamit. A probléma pedig hogy workaroundot kell találni egy problémára aminek nem szabadna léteznie.

"tördelje a mailer progi, de csak az enkódolt adatot!"

Van értelme egyáltalán akármit is tördelni? Számít az a megjelenítést leszámítva, ha nincs tördelve a szöveg? Szerintem az ideális megoldás az lenne, hogy a mail program alapból nem csinál semmit (ez legyen az alapbeállítás, ne kikapcsolható legyen). És megjelenítésnél betördeli, mint ahogy azt egyébként is tenné akármilyen szövegmegjelenítő.

Van értelme egyáltalán akármit is tördelni?

ha a transfer-enkódolt adatról beszélünk, akkor tördelés helyett szerencsésebb szegmentálásról beszélni, mivel ez az adat - igaz hogy pl. quoted-printable kódolás esetén akár még embernek is olvasható - nem emberi fogyasztásra szánt adat! az olvasandó szöveget enkapszulálja a transfer-encoding, azt enkapszulálja a MIME multipart, azt enkapszulálja az SMTP, azt enkapszulálja az TCP, azt enkapszulálja az IP ...
minden rétegben lehet enkódolás, szegmentálás/fragmentálás. az más kérdés h egyes rétegek közt mennyire nagy a változás.

olvasandó szöveg -> transfer-encoded content között megcsinálja az enkódolást mondjuk base64-be, aztán a kapott adatot 72 bájtosával szegmentálja és CRLF-vel zárja a szegmenseket, mint ahogy pl. az Ethernet-II bont keretekre az IP csomagokat.

abban egyetértünk, hogy az encode/decode eljárásnak kölcsönösen egyértelműnek kéne lennie.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( kmARC v | 2016. 06. 14., k – 13:03 )

vim -> :set tw=9999 -> gggqG -> boldogsag.

( Hiena v | 2016. 06. 14., k – 13:35 )

html mail = cancer Okay?
Az email szöveges üzenetek küldésére lett kitalálva, csak nyers, formázatlan szövegekére. Megértem, hogy nagyon nehéz plain textben javascriptes adathalász oldalt összehozni beágyazott képekkel, magától megnyíló linkekkel és társaival, de pont ezért kellene izzó szívlapáttal tarkón baszni azt aki kitalálta, hogy a levelezőkliensek automatikusan megjelenítsenek html-t.
Nincs olyan indok, ami miatt egy emailben karakterméret, beszúrás, vagy bármilyen más formázásnak kelljen, hogy szerepeljen. Miért? Mert az emailnél nincs előre meghatározva, hogy a fogadónak a kliense milyen formában tudja megjeleníteni az üzenetet. Ha kritikus a levél formázása, akkor ott a lehetőség, hogy olyan formátumban csatolja a felhasználó az üzenetet, ami az igényeinek a legjobban megfelel.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Megértem, hogy nagyon nehéz plain textben javascriptes adathalász oldalt összehozni beágyazott képekkel, magától megnyíló linkekkel és társaival, de pont ezért kellene izzó szívlapáttal tarkón baszni azt aki kitalálta, hogy a levelezőkliensek automatikusan megjelenítsenek html-t."

Normális esetben ilyesmi miatt nem kellene aggódni. Valójában... egyáltalán kell? Milyen klienst használsz, ami magától megnyit linkeket, és adathalász javascriptet futtat?

Őszintén szólva szerintem nincs probléma azzal, ha az emailek tartalma nem csak egy merev, formázatlan szöveg, ha fel lehet dobni egy kicsit. Nekem alkalmanként összefoglalókat kell írnom, és nem csatolhatok egy pdf-et, vagy doc fájlt a visszakereshetőség érdekében, és nem is akarok, mert azt az 1-2 oldalt kényelmesebb összeírni az email kliensben. És nagy formázásra ehhez nincs is szükség, de az áttekinthetőséget nagyban segíti hogy tudok rendes felsorolásokat írni, és alap formázásokkal kiegészíthetem a mondanivalómat.

A probléma sokkal inkább az, hogy a szabvány egyáltalán nem szabvány, és az, hogy egyesek visszaélnek vele.

Külön öröm, ha színes szöveget szerkesztenek bele a html levélbe. Plain text olvasom. Azért, mert.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Ha kritikus a levél formázása, akkor ott a lehetőség, hogy olyan formátumban csatolja a felhasználó az üzenetet, ami az igényeinek a legjobban megfelel."

ez tok jo otlet, hasznalhatnank erre valami szabvanyos formatumot es akar automatikusan megjelenithetne a levelezo ha a user ugy allitja be!

--
NetBSD - Simplicity is prerequisite for reliability

( uid_17626 | 2016. 06. 15., sze – 08:16 )

Szerintem ezen kár idegeskedni. Csak van a környékeden olyan aki ért hozzá és meg tudja oldani! :P

( Zahy v | 2016. 06. 15., sze – 20:50 )

Vegyük mindehhez a reply.reply.reply.reply tipusú leveleket, ami 30 MB, amiből 29,8 MB az egyes küldők automatikus, 30 soros aláírása, netán koronás logós gifekkel megtűzdelve (meg az ezereggyel ezelőtti teljesen érdektelen előzmény. Hányadék. Az e-mail az plain textre van kitalálva, és ha az nem elég akkor arra vannak szabványok, amiket korrekten kell az egyes kliensekben implementálni. Lásd még WINMAIL.DAT TNEF csoda.

Azzal a felével amúgy egyetértek, hogy a kliens tördeljen - de túl sokszor találkozom/kell együttéljek olyan klienssel, amelyik ezt nem teszi. Így aztán Ha rajtam múlik, én magam is tördelek :-)

"Az e-mail az plain textre van kitalálva, és ha az nem elég akkor arra vannak szabványok, amiket korrekten kell az egyes kliensekben implementálni."

A téma arról szól, hogy szarul teszi, azaz minden másra alkalmasabb, mint sima szöveg átvitelére. Már amennyiben tényleg a küldő fél kliense összezagyválja az üzenetet mert csak alapon. Szerintem ez lazán bug, és reportolni kéne.

(az enyémet nem tudom, geany-ben írok emaileket, 72-es sorhosszal)