Connect. Communicate. Collaborate. Securely.

Domů » Česky » Kerio Connect » Kerio connect 8 a dekodovaní zpráv pro iphone a mac (PROBLEM S WINMAIL.DAT)
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
Zdravim,
bohužel až teď jsem dostal informaci že už tak měsíc máme problém s dekodovanim zpráv pro iphone/mac os x 10.8.2. Když nepovolim dekodování zpráv TNEF, mám v pořádku tělo mailu ale přílohu jen winmail.dat. To je v pořádku, to je jasné. Ale když dekodování zapnu dostanu něco takového .. {\rtf1\ansi\fbidis\ansicpg1250\deff0\deftab720\fromtext{\fon ttbl{\f0\fswiss\fcharset238 Times New Roman;}{\f1\fswiss\fcharset2 Symbol;}} {\colortbl;\red192\green192\blue192;} {\*\generator Microsoft Exchange Server;} {\*\formatConverter converted from text;} \viewkind5\viewscale100 {\*\bkmkstart BM_BEGIN}\pard\plain\fs20\f0{Zdrav\'EDm,\line \line pos\'EDl\'E1m sc\'E9n\'E1\'F8 a ko\'9Ailku k repce Hrachovcov\'E1 cvi\'E8\'ED j\'F3gu.\line \line Eva}}
Co s tim, nedávám vinnu Keriu, mohlo se "něco" změnit v Keriu či na Exchange, ale to šéfa moc nezajímá. Nejhorší je, že u nás kromě verze Keria se nic nezměnilo. Stačilo by mi potvrzení, že když se třeba vrátim na verzi 7.4.něco, že mi to vyřeší tento problém. Dík za rady.

MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
Tento problém není vázaný na verzi Kerio Connectu. Jediným spolehlivým řešením je požádat odesílatele, aby neposílal emaily v TNEF (winmail.dat) formátu. Vetšinou se to stane, když si někdo na Exchange přidá adresáta do kontaktů - pak se Exchange zblázní a posílá emaily ve svém proprietárním formátu.

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
Díky za info, nicméně jako vydavatelství časopisu a internetových medií máme tudíž i mraky mailové komunikace a moc si neumím představit jak budu všechny spolupracující mající Exchange kontaktovat a vysvětlovat jim, že je "problém" či nevhodné nastavení u nich přestože problémy s poštou máme jen my. Sad

[Aktualizováno: Út, 05 březen 2013 01:48]


MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
Můžete samozřejmě reportovat chybu Applu, protože neumí správně zobrazit RTF tělo zpráv ve většině svých klientů (i když v Apple Mail na OS X 10.7 to umí). Chybu mají reportovanou už asi 5 let, ví o ní, a neřeší.

V ostatních emailových klientech problém není.
Zvažujeme možnost RTF část emailu prostě ignorovat, nicméně pak by v emailu zůstal pouze plaintext, bez formátování.

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
S tim applem to nevidim optimisticky Wink Určitě můžete zadat můj hlas pro "násilnou konverzi těla zpráv na plain text" (minimálně možnost nechat rozhodnout admina mail serveru) protože sám musíte tušit, že reálný úspěch nebude mít obvolávání spolupracujících firem a vysvětlování jim, že RTF formát u našich pár iphonistů/macistů si nikdo z nich moc nepočte. A samozřejmě okamžitě následuje otázka: a jak to ostatnim to funguje? To nebude chyba u nás.." no a pak pokračuje boj argumentů. Každopádně se chci zeptat, jak jednodušše poznám třeba z hlavičky mailu jestli byla TNEFem dekodována nebo ne? Mám tu mail problémový a neproblémový a problémový má v hlavičce u položky "X-MS-TNEF-Correlator" vyplněný sáhodlouhý údaj a ty bezproblémové z téhož Exch. tam nemají nic. Jde mi o to, že debug log nemusím mít pokaždé zapnutý.

MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
V podstatě jste na to přišel sám. Pokud je v emailu hlavička X-MS-TNEF-Correlator a v ní nějaký sáhodlouhý údaj, pak byla zpráva odeslána v TNEFu. Pokud není nebo je prázdná, tak odesílací server použil normální MIME formát.

Ostatním to funguje většinou asi proto, že používají emailové klienty, kteří hloupě nezobrazují části emailu, které neumí zobrazit. Většinou si vyberou plaintext alternativu. Anebo jejich server neumí dekódovat TNEF vůbec a chodí jim emaily s přílohou winmail.dat. Pokud mají štěstí a používají Microsoft klienta (např. Outlook), tak ten jim to dekóduje.

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
Tak a teď babo raď Smile Tak teď mám 1 email, poslaný na 2 adresy u nás. User1 (tomu šla cc:) má ten údaj v hlavičce prázdný a user2 (to:) má ten údaj vyplněný. Samozřejmě usr 1 ok, usr2 KO. Oba uživatelé maji iphone. Nevim jestli hraje roli zda se na mail podivali nejdřív na iphonu a pak v mailovym klientu, ALE user1 má na PC klienta Outl. 2010 s koff a druhý má POUZE mac a macovského maila. Tohle je asi NEJVĚTŠÍ PRŮŠVIH kolem toho dekodování. Tohlu situaci jsem opravdu neočekával. Já zkusim zítra telefonický support jestli tamn máme ještě nějaký ten incident zdarma. To zpoplatnění to je teda něco.. Sad((

MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
Podívejte se do hlaviček zpráv, hlavně na Message-ID. Budou se lišit. Podle všeho odesílatel poslal dvě verze té samé zprávy, pro každého příjemce jinou (a v jiném formátu).

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
message id shodné, opravdu. Zkopíroval sem si hlavicky do souboru a porovnávám podle obsahu. User1 ten co je v pohodě MÁ v hlavičce TYTO POLOŽKY až na předposledních 2 řádcích:
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

User2 výše zmíněné řádky nemá ale MÁ tyto hned po received a čase přijetí TYTO:
Content-Type: multipart/mixed;
boundary=" _000_A8705D12DF4C924A8ACB51E5A745CF54BE132C89DAservergabriel _ "

a samozřejměpoložku X-MS-TNEF

v nejhoršim bych mohl přiložit ty hlavičky, ale musim pročistit tajná data Smile))

MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
Zkuste se ještě podívat do mail logu na server, jestli zpráva pro oba příjemce přišla v jedné kopii nebo ve dvou.

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
Queue-ID se liší

Msg-Id: <A8705D12DF4C924A8ACB51E5A745CF54BE132C89DA<at>...
Msg-Id: <A8705D12DF4C924A8ACB51E5A745CF54BE132C89DA<at>...

a liší se i velikosti

a do TNEFu šla jen jedna:

[07/Mar/2013 16:38:39][3724] {msgdecode} Known message class (1) has been discovered within the main part of TNEF.
[07/Mar/2013 16:38:39][3724] {msgdecode} TNEF part of message D:\MAILSTORE/queue/0c/5138b47e-00017333.eml decoded.

[Aktualizováno: Čt, 07 březen 2013 22:34]


MK
  •  
Pavel Dobrý (Kerio) je nyní offline Pavel Dobrý (Kerio)

Příspěvky: 1550
Odeslat poštu tomuto uživateli
V tom případě odesílatel vyrobil dvě verze emailu, pro každého příjemce jinou. Což vysvětluje, proč to každý vidí jinak.
Ovšem důvod, proč Exchange někomu posílá TNEF, i když příjemce není v interní Exchange doméně je otázka spíše na Microsoft nebo správce daného serveru.

Databáze znalostí: http://kb.kerio.com/
Technická podpora: http://www.kerio.cz/cz/support
  •  
MiKy je nyní offline MiKy

Příspěvky: 17
Odeslat poštu tomuto uživateli
to spíš server vyrobil 2 verze, pak ale nechápu jak by mohly mít stejné msg-id, uživatel by těžko dokázal udělat 2 zprávy se stejnym message-id

každopádně máte pravdu. Archivuji pro všechny případy příchozí poštu ještě před jakýmikoliv úpravami. Ta co šla do TNEFu je i větší

[Aktualizováno: Čt, 07 březen 2013 22:46]


MK
Předchozí téma: Sdílený kalendář vers outlook
Další téma: Nástroje třetích stran
Jít na fórum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Aktuální čas: Ne lis 19 02:21:25 CET 2017

Celkový čas potřebný k vygenerování této stránky: 0.00516 vteřin
.:: Kontakt :: Domů ::.
Běží na: FUDforum 3.0.4.