No szóval: pár hónapja tűnt fel. Összesen egyetlen emberrel kapcsolatban észlelem a hibát. Ha történik köztünk egy-két send-reply, akkor valamelyik körben (általában elég hamar) az tűnik fel, hogy olvasni ugyan tudom a levelét, de az elolvasás utáni reply-nál elveszik a levél végéből valamennyi. Van hogy csak pár sor, az előbb kb a 70 %-a. Ez alatt azt értem, hogy az adatbeviteli ablakban már csak igen kevés része látszik a beidézett levélnek.
Ha valakinek ennyi információ elég, akkor okosítson fel - kinek mijét kell levágni, megfőzni, stb, ha a célom az, hogy mégis menjen a dolog. Mivel a webmail nem az enyém, igy gőzöm nincs mit és hogyan állitottak be. Ha valakinek ennyitől nem gyúlt fény az agyában, akkor nehezítem a dolgot. Én FreeBSD, ő FreeBSD. Én Opera, ő Opera. Én ugye Roundcube, ő GMail. (Most direkt megnéztem, Chromium alatt pont ugyanúgy lenyelődik a levél 3/4-e. Valamint FF alatt is. De most ezért nem feltétlenül butulnék egy Linuxot/bármi egyebet - egyszerűen az az érzésem, nem a kliensen áll vagy bukuk a dolog.)
Hozzászólások
Roundcube-eknak dobtal mar bugreportot?
Ezek hosszu vagy egyszavas emailek? Milyen roundcube verzio?
Nem lehet, hogy egyik levél végén "-- " van?
Ugye ezzel jelölöd az aláírást, amit általában levágnak a lev.progik válasznál.
Nálam így szokott kinézni a nagykötőjel is, ha az akármilyen program nem javítja ki és én meg lusta vagyok előszedni a karaktertáblát. Gondoltam leírom, hátha nem csak én vagyok így a dologgal.
a.) Ezt a Roundcube alkalmazást nem lehet esetleg pl. valami IMAP-os levelezőklienssel elérni? Ha igen, érdemes lenne azt is kipróbálni szvsz, hátha a webes részben levő dolgokra lehet leszűkíteni a hibát, vagy kiderülhet, hogy maga a szerverrész -- amely mind a webes, mind az IMAP-os dolgokat is kiszolgálhatja -- mélyén van valami probléma...
b.) Nem lehet, hogy a szerveroldalon van valami méretkorlát, vagy a küldött szöveg bizonyos részei ,,izgatják'' erre a cselekvésre a szervert?
G.
============================================
"Share what you know. Learn what you don't."
Ki a backend?
Ha Exchange, akkor a hibajelenség tipikus, ugyanis az mindig rosszul jelenti le a levél méretét. Egészen pontosan akkor jelent rosszul, ha a levélforrásban sok a base64 encoding, ugyanis a méretnél a text/html part byte méretét adja vissza, ami a b64 decoding utáni. Ez tipikusan 3/4-ed méret :)
Hint: IMAP::Client
--
PtY - www.onlinedemo.hu
Közös válasz. RC-nek bugreport még nem volt, verziójáról, backendjéről fogalmam sincs, mint ahogy a szolgáltató felé se jeleztem. Az utóbbi napok tesztjei alapján valahogy a GMail webes felületének idézésével van gond, ha az idézés végén kevesebb "Enter"-t üt a túloldal a kelleténél, akkor olvasni még tudom, de a válasz pontosan ennél az összefolyó idézetnek a végénél összeszarja magát. Magyarul ha valaki top-post levelezik, akkor semmi gond, de bottom-post vagy inter-post mail-eknél úgy tűnik könnyű belefutni.
(Úgy tűnik könnyen reprodukálhatónak, hogy én -> GMail , itt reply, majd ha ezt nem figyelmesen szerkeszti, akkor erre már romlik az én reply-om.)
Tehát milyen imap backend van a roundcube mögött?
A csonkolt emailek forrását megnézted? Nem b64-es encoding a text/html part?
--
PtY - www.onlinedemo.hu
Felhasználóként hogy tudom megnézni a RC backendjét? (Magát az e-mailt hamarosan megnézem.)
Ha adnak nemwebmailt is, akkor telnetelsz a pop3 vagy imap portra is beszélgetsz a szerverrel.
OK, hülye vagyok. POP3/IMAP4 is Dovecot-ot mond magáról
Na, innentől érdekes a dolog... Azért nézz már meg néhány email fejlécet, mert ha Exchange-re csattan be, és a dovecot alá meg máshogy kerül oda, lehet az még bugforrás.
Ha nincs közben ilyen móka, akkor viszont elképzelni sem tudom az okát. Nekem is van RC-om Dovecot fölött (igaz, csak a karantént nézem vele), de minden spam olyan szépen látszik, nem csonkolt egyik sem - igaz, nem is válaszolgatok nekik, ki is lett pucolva az RC-ból a küldés/szerkesztés feature.
--
PtY - www.onlinedemo.hu
Le lehet tölteni a levél forrását, úgyhogy ha az jó->roundcube bug, ha az már eleve nem jó, akkor meg más...