Pošta - Webové rozhraní - Novinky: Porovnání verzí

Z More
Přejít na: navigace, hledání
m (→‎dílčí upgrade serveru, 10.8.2010)
m (→‎záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014: typo)
 
(Nejsou zobrazeny 3 mezilehlé verze od 2 dalších uživatelů.)
Řádka 2: Řádka 2:
  
 
__NOTOC__
 
__NOTOC__
 +
 +
=== záplata RFC 4408 SPF, SRS a přeposílání zpráv, 23.7.2014 ===
 +
 +
Některé poštovní servery, včetně toho našeho, se chrání před nevyžádanou poštou také pomocí [http://cs.wikipedia.org/wiki/SPF SPF]. Pokud chráněný cílový server obdrží zprávu podepsanou odesílatelem z chráněné domény (ani jedno není povinné, ale pokud se sejdou obě podmínky, SPF se bude aplikovat, jinak ne), ale odeslanou z počítače, který k tomu není autorizován (typicky [[Pošta - SPAM | spam]]), server zprávu nepřijme. Problém může nastat, pokud mail do cílového serveru nepřijde přímo od odesílatele, ale přes prostředníka.
 +
 +
'''Popis problému:''' Česká spořitelna (doména <code>csas.cz</code>) chrání svou doménu tak, že určuje seznam jejích autorizovaných poštovních serverů. Z banky našemu uživateli pošlou mailem do jeho firemní schránky v našem serveru zprávu. Náš uživatel je ale na cestách, a tak si přechodně nechá veškerou poštu přeposílat na svou soukromou schránku na Seznam.cz. Tento server je cílem zprávy z banky a tento server aplikuje SPF politiku. Doména České spořitelny ale říká, že náš server není k doručování podobné pošty určen, takže Seznam.cz mail od našeho serveru nepřijme. Náš server vrátí mail odesílateli (bance) jako neodručitelný kvůli problému na Seznam.cz (ve skutečnosti to ale banka poslala na firemní účet na našem serveru, takže jsou trochu zmateni).
 +
 +
'''Řešení:''' Cesta požádat ČS o zařazení našeho serveru do seznamu autorizovaných stejně jako požádat Seznam.cz o vyřazení našeho serveru z kontroly je jednak neschůdná, jednak neřeší problém pro další servery (např. GMail, další oblíbený cíl přeposílaných mailů uživatelů našeho serveru, také kontroluje SPF). Univerzální řešení nabízí [http://www.openspf.org/SRS SRS]. Jeho zkušební verze byla dnes na náš server implementována.
 +
 +
Nyní by se již odesílatelům neměly vracet přesměrované maily jako nedoručitelné z důvodu SPF, tyto maily by totiž měly být doručeny do cílového serveru bez problémů (tedy pokud nenastanou jiné příčiny, např. plná schránka, zablokovaný účet apod.). Pokud se Vám přesto vyskytnou výše popsané problémy, dejte nám prosím vědět [mailto:mail-upgrade@admin.more.cz mailem].
 +
 +
=== záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014 ===
 +
 +
Uživatelé se dlouhodobě potýkali s problémem zobrazení zpráv zaslaných z webového rozhraní [http://www.seznam.cz/ Seznam.cz] a zobrazených v poštovních programech [http://www.nicrosoft.com/ Microsoftu], např. MS Outlook, Outlook Express, Windows Live Mail. Zájemcům postiženým tímto problémem jsme bezplatně poskytli [http://www.it8.cz/download/PVCfix.jar opravný nástroj] v naději, že si Microsoft chybu opraví.
 +
 +
'''Popis problému:''' Seznam.cz do zpráv vkládá záhlaví, které je svou délkou na hranici specifikace formátu zpráv (RFC 2822). Server v souladu se specifikací formátu dlouhých záhlaví (RFC 2231) takový řádek rozdělí na dva. Bohužel, žádný z MS produktů (kromě nejnovější mailové čtečky [http://windows.microsoft.com/cs-cz/windows-8/mail-app-tutorial Pošta pro Windows 8.1]) neimplementuje RFC 2231, takže jsou takové zprávy nečitelné (lidově "rozsypaný čaj").
 +
 +
'''Řešení:''' dočasně bylo možné jednotlivé postižené zprávy "opravit", tedy vrátit zprávu před aplikaci RFC 2231, pomocí naší [http://www.it8.cz/download/PVCfix.jar aplikace]. Nyní je náš server méně citlivý na délku záhlaví a ponechá řádek příliš dlouhý, nicméně tomu Outlook rozumí a zprávu zobrazí správně (skoro, obvykle se v textu vyskytuje jeden znak "<code>=</code>", který odesílatel nenapsal, navíc).
 +
 +
Dalším problémem byly zprávy odeslané z Outlooku (a dalších MS poštovních programů), které v záhlavích Od/Komu/Kopie obsahovaly současně znak s diakritikou a současně alespoň jeden ze znaků "<code>.;:\@</code>". Do pole Komu a Kopie se taková kombinace znaků může dostat z adresáře nebo z odpovědi na jinou zprávu, pole Od (Odesílatel) si uživatel nastaví sám. A to je právě nejčastější zdroj chyb.
 +
 +
'''Popis problému:''' např. pan Novák z firmy ABC s.r.o. si do odesílatele uvede "<code>J. Novák - ABC s.r.o. <jnovak@example.com></code>", kvůli diakritice se ale záhlaví zprávy musí zakódovat, ale to Outlook udělá špatně, přesněji v příkrém rozporu se specifikací formátování ne-ASCII znaků (RFC 2047). Toto špatné kódování způsobí na straně serveru nejen neschopnost správně pochopit záhlaví, ale i při získávání informací o odesílateli ztrátu informace s emailovou adresou. Pokud je příjemce uživatelem Outlooku nebo podobné poštovní čtečky nebo stahuje maily pomocí POP3 a pokusí se na mail obsahující tuto poškozenou hlavičku odpovědět, nepodaří se mu to, protože v odesílateli díky špatnému kódování chybí elektronická adresa, zbyde jen špatně zobrazené jméno, např. <code>=?iso-8859-2?q?J._Nov=A3k_-_ABC_s.r.o.?=</code>.
 +
 +
'''Řešení:''' Opět je řešení na straně Microsoftu (řádná implementace RFC 2047) a opět zůstává toto řešení jen zbožným přáním. Problém lze obejít i tak, že odesílatel nepoužije současně diakritiku a současně znaky, které Outlook chybně kóduje (pokud takový mail obdržíte, požádejte odesílatele, aby nepoužíval diakritku v poli odesílatele). Na našem serveru je nyní záplata, která zajistí, že se server nepokusí chybně kódované záhlaví opravit, pouze ho nechá, jak je, chybně, ale zdá se, že Outlook tuto svou chybu správně interpretuje, takže zůstává jen problém, pokud čtete maily odeslané z Outlooku jinou čtečkou. Např. naše webové rozhraní nedokáže správně zobrazit odesílatele v seznamu zpráv, ale pokud si už čtete detail zprávy nebo na zprávu odpovídáte, jsou jméno i adresa správně zobrazeny a interpretovány, takže na mail lze bez problémů odpovědět.
 +
 +
Pokud se Vám vyskytnou výše popsané problémy se čtením zpráv, dejte nám prosím vědět [mailto:mail-upgrade@admin.more.cz mailem].
 +
 +
=== dílčí upgrade serveru, 22.8.2012 ===
 +
 +
* doručovací server [http://www.postfix.org/features.html Postfix 2.8.10]
 +
* poštovní server [http://dbmail.org/index.php?page=overview DBMail 3.0.2]
 +
* webový server [http://httpd.apache.org/ Apache 2.2.22]
 +
* aplikační platforma [http://php.net/ PHP 5.3.13]
 +
* databázový server [http://mysql.com/ MySQL 5.5.23]
 +
* antivirový server [http://clamav.net/ ClamAV 0.97.3] <small>[průběžná aktualizace]</small>
 +
* integrační kontrola obsahu [http://www.ijs.si/software/amavisd/ amavisd-new 2.6.6]
  
 
=== dílčí upgrade serveru, 10.8.2010 ===
 
=== dílčí upgrade serveru, 10.8.2010 ===

Aktuální verze z 31. 7. 2014, 12:02

Nápověda webového rozhraní pošty: Nápověda

 Nová zpráva  Adresář  Složky  Možnosti  Hledat  Nápověda  Sdílené složky  Kalendář

https://mail.more.cz

 Začínáme  Jak na to  Často kladené otázky  O webovém rozhraní pošty  Novinky  Zprávy  Požadavky


záplata RFC 4408 SPF, SRS a přeposílání zpráv, 23.7.2014

Některé poštovní servery, včetně toho našeho, se chrání před nevyžádanou poštou také pomocí SPF. Pokud chráněný cílový server obdrží zprávu podepsanou odesílatelem z chráněné domény (ani jedno není povinné, ale pokud se sejdou obě podmínky, SPF se bude aplikovat, jinak ne), ale odeslanou z počítače, který k tomu není autorizován (typicky spam), server zprávu nepřijme. Problém může nastat, pokud mail do cílového serveru nepřijde přímo od odesílatele, ale přes prostředníka.

Popis problému: Česká spořitelna (doména csas.cz) chrání svou doménu tak, že určuje seznam jejích autorizovaných poštovních serverů. Z banky našemu uživateli pošlou mailem do jeho firemní schránky v našem serveru zprávu. Náš uživatel je ale na cestách, a tak si přechodně nechá veškerou poštu přeposílat na svou soukromou schránku na Seznam.cz. Tento server je cílem zprávy z banky a tento server aplikuje SPF politiku. Doména České spořitelny ale říká, že náš server není k doručování podobné pošty určen, takže Seznam.cz mail od našeho serveru nepřijme. Náš server vrátí mail odesílateli (bance) jako neodručitelný kvůli problému na Seznam.cz (ve skutečnosti to ale banka poslala na firemní účet na našem serveru, takže jsou trochu zmateni).

Řešení: Cesta požádat ČS o zařazení našeho serveru do seznamu autorizovaných stejně jako požádat Seznam.cz o vyřazení našeho serveru z kontroly je jednak neschůdná, jednak neřeší problém pro další servery (např. GMail, další oblíbený cíl přeposílaných mailů uživatelů našeho serveru, také kontroluje SPF). Univerzální řešení nabízí SRS. Jeho zkušební verze byla dnes na náš server implementována.

Nyní by se již odesílatelům neměly vracet přesměrované maily jako nedoručitelné z důvodu SPF, tyto maily by totiž měly být doručeny do cílového serveru bez problémů (tedy pokud nenastanou jiné příčiny, např. plná schránka, zablokovaný účet apod.). Pokud se Vám přesto vyskytnou výše popsané problémy, dejte nám prosím vědět mailem.

záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014

Uživatelé se dlouhodobě potýkali s problémem zobrazení zpráv zaslaných z webového rozhraní Seznam.cz a zobrazených v poštovních programech Microsoftu, např. MS Outlook, Outlook Express, Windows Live Mail. Zájemcům postiženým tímto problémem jsme bezplatně poskytli opravný nástroj v naději, že si Microsoft chybu opraví.

Popis problému: Seznam.cz do zpráv vkládá záhlaví, které je svou délkou na hranici specifikace formátu zpráv (RFC 2822). Server v souladu se specifikací formátu dlouhých záhlaví (RFC 2231) takový řádek rozdělí na dva. Bohužel, žádný z MS produktů (kromě nejnovější mailové čtečky Pošta pro Windows 8.1) neimplementuje RFC 2231, takže jsou takové zprávy nečitelné (lidově "rozsypaný čaj").

Řešení: dočasně bylo možné jednotlivé postižené zprávy "opravit", tedy vrátit zprávu před aplikaci RFC 2231, pomocí naší aplikace. Nyní je náš server méně citlivý na délku záhlaví a ponechá řádek příliš dlouhý, nicméně tomu Outlook rozumí a zprávu zobrazí správně (skoro, obvykle se v textu vyskytuje jeden znak "=", který odesílatel nenapsal, navíc).

Dalším problémem byly zprávy odeslané z Outlooku (a dalších MS poštovních programů), které v záhlavích Od/Komu/Kopie obsahovaly současně znak s diakritikou a současně alespoň jeden ze znaků ".;:\@". Do pole Komu a Kopie se taková kombinace znaků může dostat z adresáře nebo z odpovědi na jinou zprávu, pole Od (Odesílatel) si uživatel nastaví sám. A to je právě nejčastější zdroj chyb.

Popis problému: např. pan Novák z firmy ABC s.r.o. si do odesílatele uvede "J. Novák - ABC s.r.o. <jnovak@example.com>", kvůli diakritice se ale záhlaví zprávy musí zakódovat, ale to Outlook udělá špatně, přesněji v příkrém rozporu se specifikací formátování ne-ASCII znaků (RFC 2047). Toto špatné kódování způsobí na straně serveru nejen neschopnost správně pochopit záhlaví, ale i při získávání informací o odesílateli ztrátu informace s emailovou adresou. Pokud je příjemce uživatelem Outlooku nebo podobné poštovní čtečky nebo stahuje maily pomocí POP3 a pokusí se na mail obsahující tuto poškozenou hlavičku odpovědět, nepodaří se mu to, protože v odesílateli díky špatnému kódování chybí elektronická adresa, zbyde jen špatně zobrazené jméno, např. =?iso-8859-2?q?J._Nov=A3k_-_ABC_s.r.o.?=.

Řešení: Opět je řešení na straně Microsoftu (řádná implementace RFC 2047) a opět zůstává toto řešení jen zbožným přáním. Problém lze obejít i tak, že odesílatel nepoužije současně diakritiku a současně znaky, které Outlook chybně kóduje (pokud takový mail obdržíte, požádejte odesílatele, aby nepoužíval diakritku v poli odesílatele). Na našem serveru je nyní záplata, která zajistí, že se server nepokusí chybně kódované záhlaví opravit, pouze ho nechá, jak je, chybně, ale zdá se, že Outlook tuto svou chybu správně interpretuje, takže zůstává jen problém, pokud čtete maily odeslané z Outlooku jinou čtečkou. Např. naše webové rozhraní nedokáže správně zobrazit odesílatele v seznamu zpráv, ale pokud si už čtete detail zprávy nebo na zprávu odpovídáte, jsou jméno i adresa správně zobrazeny a interpretovány, takže na mail lze bez problémů odpovědět.

Pokud se Vám vyskytnou výše popsané problémy se čtením zpráv, dejte nám prosím vědět mailem.

dílčí upgrade serveru, 22.8.2012

dílčí upgrade serveru, 10.8.2010

Případné problémy prosím hlaste mailem.

celkový upgrade společného serveru, 19.6.2010

Poštovní server plně aktualizován. Pokud se vyskytnou problémy při jeho používání (zejména nežádoucí změna nebo omezení funkcionality), dejte nám prosím vědět.

Server byl rovněž přestěhován do lokality s vyšším stupněm zabezpečení a vyšší kapacitou připojení.

zvýšení limitu velikosti příloh, 2.11.2010

Jednotlivý mail, který náš poštovní server přijal pro zpracování (k odeslání nebo doručení), mohl mít maximální velikost 10 MB. Nyní se tento limit zvyšuje na 100 MB na jednu zprávu. Nezpomeňte, že se z historických důvodů binární přílohy vkládají do mailové zprávy zakódované, takže oproti velikosti, kterou u přílohy ukazuje správce souborů, budou v mailu zabírat přibližně o třetinu větší prostor (efektivně lze tedy přiložit k mailu až 75 MB binárních dat).

Stále platí omezení velikosti jedné zprávy u cizích poštovních serverů, pokud je mail větší než 10 MB, mohou nastat problémy s doručením. Kromě toho, že se s rostoucí velikostí mailu snižuje spolehlivost přenosu, zvyšuje se také celková doba potřebná na doručení (odeslání, zpracování, antivirová a antispamová kontrola, předání cílovému serveru, zpracování cílovým serverem, uložení) a riziko, že mailem adresátovi zaplníte jeho schránku.

Dále byl zvýšen limit z 8 MB na 16 MB binární velikosti jednotlivé přílohy prostřednictvím webového rozhraní. Větší přílohu lze rozdělit na menší části a až do velikosti 100 MB zprávy (75 MB binárních příloh) zprávu naplnit. I zde však platí, že s většími přílohami se obtížněji manipuluje a v závislosti na typu připojení může během odesílání přílohy na server docházet k výpadkům způsobeným prodlevami při přenosu velkých objemů dat.

Velké přílohy používejte na vlastní riziko.

upgrade modulu automatického přidávání adres, 24.5.2010

Modul na přidávání adres z mailu byl aktualizován. Nová verze umí převzít adresy do adresáře nejen z odesílatele, ale i z příjemců a, podle nastavení, i z těla zprávy. Adresy lze získávat i z odesílaných zpráv, a to i automaticky.

Pokud objevíte nesprávnou lokalizaci do češtiny příp. jinou závadu, dejte nám prosím vědět.

vypršela životnost antivirového systému, 16.4.2010

Na základě oznámení byl dne 15.4.2010 ukončen životní cyklus antivirového systému použivaného poštovním serverem, ClamAV 0.94.2-1. Vzhledem k tomu, že stávající operační systém serveru (Fedora 10) nemá novější aktualizaci, byl antivirový program aktualizován manuálně na verzi 0.96/10751. Do doby, než bude operační systém zahrnovat tuto nebo novější verzi, nebude antivirový program aktualizován (to se netýká aktualizací virových signatur, ty jsou aktuální nepřetržitě).

Ukončení životního cyklu antivirového programu proběhlo celosvětově a bylo zaznamenáno několik poštovních serverů, které se s ukončením činnosti nevypořádaly včas. Dokud správci těchto serverů své poštovní servery neošetří vhodným způsobem, může být pozdrženo doručování některých e-mailů, příp. se mohou i vracet svým odesílatelům.

chybná diakritika a nerozpoznané přílohy, 16.3.2010

Opraveno:

  • panel Nová zpráva má místo polí Komu, Předmět, Kopie a Skrytá kopie anglické ekvivalenty
  • občas se v poli odesílatele v seznamu zpráv (příjemce ve složce Odeslaná pošta) objeví poškozená adresa (=?iso-8859-2...)
  • pokud příloha TNEF (winmail.dat) nemá korektní příznak typu přílohy (např. application/pdf), je třeba přílohu nejprve uložit a pak otevřít v novém okně

nečitelné přílohy winmail.dat z MS Outlook, 13.3.2010

Opraven problém s rozpoznáním obsahu zprávy poslané z MS Outlook v tzv. TNEF formátu (příloha winmail.dat).

celkový update systému, 13.3.2010

Poštovní server plně aktualizován. Pokud se vyskytnou problémy při jeho používání (zejména nežádoucí změna nebo omezení funkcionality), dejte nám prosím vědět.

oprava nefunkční změny hesla, 19.2.2010

Nástroj na změnu přístupového hesla poštovní schránky byl opraven.

nepřijímané notifikace datových schránek, 30.11.2009

Projekt datových schránek umožňuje zasílat oznamovací zprávy (notifikace) pomocí elektronické pošty. Zprávy přicházejí z adresy notifikace@mojedatovaschranka.cz. Doména odesílatele notifikace je (v době psaní tohoto příspěvku) chráněna službou SPF, ale jen v testovacím režimu. Poštovní server tedy tuto ochranu ignoruje.

Implementátoři notifikačního systému však kromě neúčinnosti SPF také neumožnili ani další z protispamových ochran - aktivní test existence adresy - elektronická adresa notifikace@mojedatovaschranka.cz neexistuje. V době psaní příspěvku příslušný server, kde se měla existence ověřit, nepřijímal žádné dotazy, a správce tohoto serveru oznámil, že to je tak navrženo:

notifikace@mojedatovaschranka.cz je odmítán vaším poštovním serverem. MX záznam neexistuje z důvodu, že se jedná o adresu, na kterou není uživatelem odpovídáno. Je zapotřebí přidat tuto adresu na SMTP whitelist.

Přestože chybu musí řešit provozovatel notifikačního systému datových schránek (stejný problém se týká všech poštovních serverů, které by měly přijímat notifikace z datových schránek), vzhledem k jeho postoji k problematice a důležitosti těchto notifikací pro naše zákazníky byla adresa notifikace@mojedatovaschranka.cz uvedena na bílé listině našeho serveru (takže se nekontroluje její existence).

Znamená to, že podle aktuálního nastavení může být do cílové schránky doručena i zpráva podepsaná notifikace@mojedatovaschranka.cz, přestože její původ nebude znám (může jít o podvrh). Kontrola existence adresy a test SPF nejsou nyní účinné.

Můžete si také přečíst článek Datové schránky (zatím) nemailují na serveru root.cz.

lokální opravy, 5.8.2009

  • automatické odpovědi v době nepřítomnosti chybně kódovaly českou diakritiku
  • při pokusu o uložení adresáta nově odeslané zprávy se zobrazílo chybové hlášení a příjemce se neuložil do adresáře

aktualizace antispamových filtrů, 3.8.2009

Činnost služby dsbl.org byla zastavena, poštovní server tedy přestal tuto službu využívat.

Naopak poštovní server rozšířil služby SBL o

(posledně jmenovaná služba zapouzdřuje všechny ostatní).

dílčí update systému, 6.4.2009

Poštovní server byl updatován. Následují verze aktualizovaných částí:

lokalizována chyba diakritiky v adresách, 6.3.2009

Po upgradu DBMail poštovního serveru dne 8.2.2009 na verzi 2.2.9 se začala u nově došlé pošty projevovat chyba zobrazení e-mailových adres v seznamu zpráv, pokud adresa obsahovala v reálném jméně (obvykle před skutečnou e-mailovou adresou) znaky s diakritikou. Problém neřeší ani zatím poslední verze 2.2.11 serveru.

Příčina problému byla lokalizována a předána výrobci serveru. Do odstranění příčiny je k dispozici náhradní řešení, které by mělo problém eliminovat. Pokud se přesto emailová adresa v seznamu zpráv zobrazí chybně, dejte nám prosím vědět.

dílčí update systému, 6.3.2009

Poštovní server byl updatován. Následují verze aktualizovaných částí:

celkový upgrade systému, 8.2.2009

Poštovní server plně aktualizován. Pokud se vyskytnou problémy při jeho používání (zejména nežádoucí změna nebo omezení funkcionality), dejte nám prosím vědět.

Jedná se tedy o nejnovější stabilní verze produktů.

Pozn.: Všechny produkty jsou instalovány balíčkovou metodou distributora operačního systému, u kterého lze předpokládat dobré sladění s operačním systémem a ostatními komponentami.

Další informace můžete najít ve starších zprávách.

Citováno z „https://wiki.more.cz/index.php?title=Pošta_-_Webové_rozhraní_-_Novinky&oldid=3080“