Pošta - Webové rozhraní - Novinky - Historie editací

Dan: /* záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014 */ typo

2014-07-31T11:02:07Z

‎záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014: typo

Misa: /* záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014 */

2014-07-29T13:52:45Z

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

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

2014-07-23T16:59:25Z

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

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

2014-07-22T10:37:47Z

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

Dan: /* dílčí upgrade serveru, 10.8.2010 */

2011-08-09T22:04:15Z

‎dílčí upgrade serveru, 10.8.2010

Dan: dílčí upgrade serveru

2011-08-09T21:59:55Z

dílčí upgrade serveru

Dan v 19. 6. 2011, 16:27

2011-06-19T16:27:56Z

Dan: zvýšení limitu velikosti příloh

2010-11-02T09:50:06Z

zvýšení limitu velikosti příloh

Dan: /* upgrade modulu automatického přidávání adres, 24.5.2010 */

2010-05-24T14:18:08Z

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

Dan: upgrade modulu automatického přidávání adres

2010-05-24T14:15:59Z

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

@@ Řádka 23: / Řádka 23: @@
 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ódóvá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>.
+'''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.

@@ Řádka 21: / Řádka 21: @@
 '''Ř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 jnou zprávu, pole Od (Odesílatel) si uživatel nastaví sám. A to je právě nejčastější zdroj chyb.
+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 neschopnost záhlaví správně pochopit a při pokusu o získání informace o odesílateli se dokonce ztratí část s emailovou adresou. Pokud je přijemce 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>.
+'''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ódóvá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.

← Starší verze		Verze z 23. 7. 2014, 16:59
Řá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 ===		=== záplata RFC 2231 a RFC 2047 pro Outlook, 17.7.2014 ===

← Starší verze		Verze z 22. 7. 2014, 10:37
Řádka 2:		Řádka 2:

	__NOTOC__		__NOTOC__
		+
		+	=== 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 jnou 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 neschopnost záhlaví správně pochopit a při pokusu o získání informace o odesílateli se dokonce ztratí část s emailovou adresou. Pokud je přijemce 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 ===

@@ Řádka 7: / Řádka 7: @@
 Případné problémy prosím hlaste [mailto:mail-upgrade@admin.more.cz mailem].
 * doručovací server [http://www.postfix.org/features.html Postfix 2.8.4]
-* poštovní server [http://dbmail.org/index.php?page=overview DBMail 3.0.0]
+* webové rozhraní [http://www.squirrelmail.org/about.php SquirrelMail 1.4.22]
-* webové rozhraní [http://www.squirrelmail.org/about.php SquirrelMail 1.4.22] <small>[vč. aktuálních a lokálních modulů]</small>
-* webový server [http://httpd.apache.org/ Apache 2.2.17]
-* aplikační platforma [http://php.net/ PHP 5.3.6]
 * databázový server [http://mysql.com/ MySQL 5.5.14]
 * antivirový server [http://clamav.net/ ClamAV 0.97.1] <small>[průběžná aktualizace]</small>
 === celkový upgrade společného serveru, 19.6.2010 ===

← Starší verze		Verze z 9. 8. 2011, 21:59
Řádka 2:		Řádka 2:

	__NOTOC__		__NOTOC__
		+
		+	=== dílčí upgrade serveru, 10.8.2010 ===
		+
		+	Případné problémy prosím hlaste [mailto:mail-upgrade@admin.more.cz mailem].
		+
		+	* operační systém [http://fedoraproject.org/wiki/ Fedora] [http://docs.fedoraproject.org/release-notes/f15/en_US/ 15]
		+	* jádro [http://www.kernel.org/ Linux Kernel 2.6.38.8]
		+	* doručovací server [http://www.postfix.org/features.html Postfix 2.8.4]
		+	* poštovní server [http://dbmail.org/index.php?page=overview DBMail 3.0.0]
		+	* webové rozhraní [http://www.squirrelmail.org/about.php SquirrelMail 1.4.22] <small>[vč. aktuálních a lokálních modulů]</small>
		+	* webový server [http://httpd.apache.org/ Apache 2.2.17]
		+	* aplikační platforma [http://php.net/ PHP 5.3.6]
		+	* databázový server [http://mysql.com/ MySQL 5.5.14]
		+	* antispamová aktivní ochrana [http://sqlgrey.sourceforge.net/ SQLgrey 1.7.6] <small>[vč. lokální úpravy]</small>
		+	* antispamový filtr [http://spamassassin.apache.org/ SpamAssassin 3.3.2]
		+	* antivirový server [http://clamav.net/ ClamAV 0.97.1] <small>[průběžná aktualizace]</small>
		+	* integrační kontrola obsahu [http://www.ijs.si/software/amavisd/ amavisd-new 2.6.4]

	=== celkový upgrade společného serveru, 19.6.2010 ===		=== celkový upgrade společného serveru, 19.6.2010 ===

← Starší verze		Verze z 19. 6. 2011, 16:27
Řádka 2:		Řádka 2:

	__NOTOC__		__NOTOC__
		+
		+	=== 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 [mailto:mail-upgrade@admin.more.cz vědět].
		+
		+	* operační systém [http://fedoraproject.org/wiki/ Fedora] [http://docs.fedoraproject.org/release-notes/f15/en_US/ 15]
		+	* jádro [http://www.kernel.org/ Linux Kernel 2.6.38.8]
		+	* doručovací server [http://www.postfix.org/features.html Postfix 2.8.3]
		+	* poštovní server [http://dbmail.org/index.php?page=overview DBMail 3.0.0]
		+	* webové rozhraní [http://www.squirrelmail.org/about.php SquirrelMail 1.4.21] <small>[vč. aktuálních a lokálních modulů]</small>
		+	* webový server [http://httpd.apache.org/ Apache 2.2.17]
		+	* aplikační platforma [http://php.net/ PHP 5.3.6]
		+	* databázový server [http://mysql.com/ MySQL 5.5.13]
		+	* antispamová aktivní ochrana [http://sqlgrey.sourceforge.net/ SQLgrey 1.7.6] <small>[vč. lokální úpravy]</small>
		+	* antispamový filtr [http://spamassassin.apache.org/ SpamAssassin 3.3.2]
		+	* antivirový server [http://clamav.net/ ClamAV 0.97] <small>[průběžná aktualizace]</small>
		+	* integrační kontrola obsahu [http://www.ijs.si/software/amavisd/ amavisd-new 2.6.4]
		+
		+	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 ===		=== zvýšení limitu velikosti příloh, 2.11.2010 ===

← Starší verze		Verze z 2. 11. 2010, 09:50
Řádka 2:		Řádka 2:

	__NOTOC__		__NOTOC__
		+
		+	=== 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 [http://cs.wikipedia.org/wiki/Base64 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 ===		=== upgrade modulu automatického přidávání adres, 24.5.2010 ===

← Starší verze		Verze z 24. 5. 2010, 14:18
Řádka 6:		Řádka 6:

	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.		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 [mailto:mail-upgrade@admin.more.cz vědět].

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

← Starší verze		Verze z 24. 5. 2010, 14:15
Řádka 2:		Řádka 2:

	__NOTOC__		__NOTOC__
		+
		+	=== 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.

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