Thunderbird - XML attachment error

Fórumok
Sziasztok!

Érdekes hibát produkál a Thunderbird. A levelezésben XML fájlt csatolok egy új levélhez. 
Elküldés után az xml fájl módosul egy rövid, 20-30 karakter hosszú sorral
(-------------- dXZxX3pvjmlmbzg880ZXQOez--) a végén. 

XML fájl:

<?xml version="1.0" encoding="Windows-1250"?>
<...>
akármi 
</> -------------- dXZxX3pvjmlmbzg880ZXQOez--

A legújabb verziót használom. 91.1.0 Az xml-t egy program generálja, eddig nem volt gond. 
Az elküldésnél egy automata olvasná be csak mivel megjelenik a végén a beszúrt kód ezért hibás a beolvasás.
Ezek a karakterek minden alkalommal megváltoznak, amikor e-mailt küldök. Letiltottam az összes 
bővítményt, és víruskeresést végeztem, de a hiba továbbra is fennáll. 
Miért van ez a kód a fájl végén? Miért ír bele a levelező az XML melléklethez küldéskor. 
Más fájltípusoknál nem találtunk ilyen hibát.

Köszönöm a segítséget

Hozzászólások

Küldöd a mellékletet tartalmazó levelet vagy továbbítod?

Küldöm, új levelet nyitok felcsatolom mellékletbe azt mehet. A felcsatolás után még jó az xml. Az elküldés után már belekerül az xml végére a változó kód. Ugyanezt a fájlt másik három gépről küldve rendben befogadják. Nincs hiba. A levelezőt már kitöröltem, újratelepítettem. 

ez a karaktersorozat a mime kontenetizaciobol adodik, ez jelzi a kontenerek hatarat

ha az elkuldott fajlt a cimzett tb-el menti le, akkor van benne/akkor is benne van ez a karaktersorozat? mert akkor tb hibanak tunik.

neked aztan fura humorod van...

Szerkesztve: 2021. 09. 10., p – 12:09

Ez az új sor nem más, mint a MIME multipart Content-Type határolója, ez mondja meg, hogy mikor kezdődik és meddig tart egy MIME multipart csatolmány tagja.
Lásd: https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1
A beolvasód rossz, nem kezeli a MIME határokat multipart Content-Type esetén.

Ezen kívül szeintem illene lezárnod az XML utolsó sorát egy újsor karakterrel.

A végén lévő sor a MIME multipart boundary. Az teljesen jó helyen van ott, ott KELL lennie, az jelzi a többi kliens számára, hogy a MIME csatolmány hol ér véget. Mondom, olvasd el a MIME szabványt, nagyon jól leírja, hogy hogyan kezelik a rendszerek a multipart MIME üzeneteket.

Szerkesztve: 2021. 09. 10., p – 20:29

Ez a levelformatum szabvanya, az elvalaszto mime "tag" kerul bele a csatolmanyba. Ha akarsz debuggolni, akkor megprobalhatod txt fajllal, xml-lel de mas kiterjesztest adsz neki, 20 karakteres xml-lel, lassuk mit ront el. Megoldast a thunderbird dev csapat tud adni, ha csinalsz egy issue-t naluk.

Szerk: kuldd zippelve, azt nem rontja el vagy a zip megoldja.

Szerk2: most latom hogy egy automata olvassa be. A thunderbird-hez semmi koze, az automata (az mi?) kezeli rosszul a levelet. 

Az automata a címzett rendszerében lévő feldolgozó szoftver ami beolvassa a rendszerébe érkező xml fájlokat. Mivel a levélküldés során az xml fájlban megjelenik a fenti hiba nem tudja értelmezni szabványos xml-ként a fogadó rendszer. Az a furcsa ha másik 3 gépről hasonló rendszerből ( levelező ugyanaz, oprendszer ugyanaz, minden ugyanaz ) küldöm a levelet ezzel az xml melléklettel nincs hiba. 1 gépnél van gond. A rendszert nem akarom újratelepíteni ezért :D - de lehet ez lesz már amennyi időt elvisz már :D

Még egyszer: az XML file nem módosul. Az szépen ott marad a helyén.

Amit te látsz, az az úgynevezett MIME boundary, a multipart üzeneteknél ez a határoló, ami megmondja, hogy az adott csatolmány meddig tart.

Ha megnézed a leveledet, fentebb lesz benne egy olyan rész, hogy 

Content-Type: multipart/mixed; 
          boundary=dXZxX3pvjmlmbzg880ZXQOez

 

Ez alapján  tudja bármelyik helyesen működő kliens, hogy az XML csatolmány mikor kezdődik, és meddig tart.

A te feldolgozód nem ilyen, nem képes kezelni helyesen a MIME multipart üzeneteket.

A Thunderbuird szabványosan jár el, jól kezeli a dolgokat, NEM módosítja az XML-t. Csak éppen a feldolgozó oldal fos, nem szabványkövető, emiatt a szabványos e-mailekkel nem tud mit kezdeni.

 

Valószínűleg a probléma az, hogy a feldolgozód soronként dolgozza fel a MIME üzenetet, és leszarja a MIME multipart boundary-t. És azt hiszi, hogy az XML file kezdeze a <?xml> kezdetű sorban van, a vége pedig a </> sorban, és az adott sorban nincs más. Ez csak akkor igaz, ha az XML file-od újsor karakterrel záródik. Ugyanis ekkor a MIME boundary a következő sor elejére kerül. Ha nem újsor karakter a vége az XML állománynak, akkor a MIME boundary (nagyon helyesen) nem kerül új sorba.

Azt nézd meg, ha már ilyen balfasz a feldolgozó programod, hogy miért áll elő olyan XML, aminek a legutolsó sora nem újsor karakterrel ér véget. Itt van a problémád (a fostartyál feldolgozóprogramon kívül), az XML előállításában, nem a Thunderbirdben. 

Köszönöm a hozzászólásokat.

Az elküldés után megnyitom az elküldött levél mellékletében lévő xml-t és belekerül a határolókód a végébe. Van még 10 gépem hasonló paraméterekkel oprendszerrel, levelezővel, víruskeresővel azokról küldve az xml fájt, minden ok.

Például van olyan a levelezőprogramban (most ne a Kitekintő Gyorsvonatra gondoljunk), hogy Nézet/Forrás, abban kellene összehasonlítani a jó meg rossz emaileket.

Valószínűleg. Biztos akkor lesz, ha sikerül rendesen kielemezni a hibát.
Pl. végeztem egy tesztet Thunderbird-del (Win, 78.14), egy sorvége nélkül meg egy sorvégés xml-fájllal, itt látható a különbség. Vagyis nem látható, mert nincs különbség:


--------------CE47E814D9EDBB618F2FAD64
Content-Type: text/xml; charset=UTF-8;
 name="proba.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="proba.xml"

<?xml version="1.0" encoding="UTF-8"?>
<eleje>Mi a mano</eleje>

--------------CE47E814D9EDBB618F2FAD64
Content-Type: text/xml; charset=UTF-8;
 name="proba_lf.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="proba_lf.xml"

<?xml version="1.0" encoding="UTF-8"?>
<eleje>Mi a mano</eleje>

--------------CE47E814D9EDBB618F2FAD64--

Üdv!

Pontosan ebbe a hibába futottunk bele mi is! Ez szerintem Thunderbird bug! Nálunk is XML-t csatolunk és ebben az esetben a TBird küldés után rosszul kódol valamit, mert az elküldött levél forráskódja már hibás. A túloldal is ezt a mime-elválasztót az XML fájl végének látja. Találtál-e rá esetleg megoldást azóta?

 

Fura, hogy nemzetközi fórumokon még nem találtam nyomát ennek a hibának. Lehet, hogy a magyar karakterkódolással lesz kapcsolatban a dolog?

 

Üdv,

TG

Nem tudtok publikalni egy levelet itt? Tehat azt es abban a formatumban ahogy a postaladaban elhelyezkedik, pl a szerveren? Szerintem itt "csak" annyi a bibi, hogy a fogado oldalon, hibasan feltetelezik, hogy a mime boundary uj sorban kezdodik.

Itt sajnos nem fogadó oldalon van a gond. Pl. sima gmail-re küldve is látszik az XML csatolmány, letöltöd gmailből az XML-t és benne van a mime elválasztó. TBird hibásan rakja össze a levél forrását (szerintem tuti valami kódolási probléma lesz az XML miatt) és a címzetti oldal a szabány alapján ezt a hibás mellékletet hámozza ki belőle.

 

Részletek az elküldött levél forrásából:

 

Fejlécben:

...

Content-Type: multipart/mixed; boundary="------------qa7n0aFegbP9XXTAkEFRpi6b"

...

 

 

 

aztán később a szöveges üzenetrész vége és az XML kezdete így néz ki, ez is ok:

...

Fax.: + ***
Mobil.: + ***
Web.: www.***.hu

--------------qa7n0aFegbP9XXTAkEFRpi6b
Content-Type: text/xml; charset=windows-1250; name="mpefj_0020145658_210922121803_N001.xml"
Content-Disposition: attachment; filename="mpefj_0020145658_210922121803_N001.xml"
Content-Transfer-Encoding: 8bit

...

 

 

És itt a gond, mert a levél forrásának a vége pedig ez:

...

    </mpl_csomag>
    </nyilvantartott_tetelek>
  </tomeges_adatok>
</jegyzek_adat>--------------qa7n0aFegbP9XXTAkEFRpi6b--

--------------qa7n0aFegbP9XXTAkEFRpi6b--

 

 

 

Tehát KÉTSZER szerepel benne a boundary!

 

Szerintem ez egyértelmű TBird bug.