Exchange server 2007/2010: Filtrace zpráv pomocí transportních pravidel

Exchange server 2007/2010: Filtrace zpráv pomocí transportních pravidel

  • Comments 10
  • Likes

Každý správce jakéhokoliv poštovního serveru nejspíš řešil problémy s nevyžádanou poštou s různými výsledky. Vestavěné nástroje v systémech MS Exchange 2007, 2010 přápadně v MS Forefront for Exchange 2010 nabízí širokou škálu konfigurací různých ochran, ale i tak se někdy najde místo, kudy se nechtěná pošta do schránek dostane. Pokud uživatel nepoužívá MS Outlook (používá například Mac OS v kombinaci s MS Entourage) a konfigurace „Junk email options“ je tedy velmi omezená, tak tím začíná známý proces zjišťování odkud, co, kdy, komu (procházení serverových logů, emailových hlaviček, kontrola konfigurace...).

Osobně jsem řešil problém s nevyžádanou poštou v azbuce, která přicházela v domén .ru a .ua. Po chvíli bádání jsem objevil způsob, jak tuto poštu eliminovat a byť je mi jasné, že řešení není univerzální, mohlo by vám pomoci alespoň k ilutraci možností, kterých se dá za pomoci transportních pravidel dosáhnout.

Představme si následující konfiguraci:

  • mx1: MS Exchange 2010 s MS Forefront for Exchange 2010
  • mx2: linux sendmail (absolutně bez jakéhokoliv filtrování příchozí pošty)

Přičemž největším problémem je větší množství nevyžádané pošty v azbuce.

Protože komunikace s žádným partnerem neprobíhá v azbuce, úkol zněl odfiltrovat veškerou příchozí komunikaci obsahující azbuku.

Po prozkoumání hlaviček doručených emailů se nabízelo několik řešení. Protože všechny emaily byly doručeny z nechráněného mx2 serveru, první zamýšlené řešení spočívalo vypnout mx2 server a nechat všechno pouze na MS Exchange a MS Forefront, ale po přehodnocení kvality ISP a několika dalších faktorů jsem tuto variantu nakonec neuskutečnil.

Dalším nadějným krokem bylo transportním pravidlem filtrovat příchozí emaily a ty třídit podle kontent typu/charsetu z hlavičky (obsahuje-li koi-8 či jiný definovaný). Tato varianta se jevila jako elegantní a přesně taková jakou jsem hledal, nicméně nefunkční. Po nastavení pravidla byla nevyžádaná pošta stejně doručována dál. Po bližším zkoumání jsem zjistil, že transportí pravidla neumějí vyhledávat v hlavičkách za středníkem - Content-Type: text/html; charset="ISO-8859-1" to znamená, že v transportním pravidle umíme identifikovat Content-Type, ale nikoliv již charset.

Po selhání předchozího pokusu jsem problém na chvíli odložil s nadějí objevení nečeho jiného později. Prošel jsem opět všechny hlavičky a hledal něco, co by emaily spojovalo a našel. Všechny emaily, co jsem měl k dispozici byly odeslány z domény *.ru . Jak jsem v úvodu zmínil, žádná naše komunikace neprobíhá v azbuce, a proto i další pokus o vyřešení směřoval zpět k transportním pravidlům. Založil jsem si testovací email na .ru doméně a vytvořil pravidlo s regulárním výrazem říkajícím, že všechny emaily odeslané z .ru domén pro začátek odfiltruji do karanténové schránky k další analýze.

Exchange_1 Exchange_2

Set-TransportRule -Identity 'Filter messages from unwanted TLD (.ru, .ua,..)' -Name 'Filter messages from unwanted TLD (.ru, .ua,..)' -Comments '' -FromAddressMatchesPatterns '(.*).ru$','(.*).ua$'

Od 1. dne aktivity tohoto pravidla jsem takto odfiltroval více než 300 emailů které by jinak skončily v uživatelských schránkách.

Outlook_1

Samozřejmě vím, že tímto pravidlem filtruji i emaily nepsané v azbuce, ale přesto je pro mé účely plně v pořádku. Jestli řešíte podobný problém, můžete pravidlo zkusit aplikovat. A v případě, že byste věděli, jak pravidla nastavit, aby filtrovala i podle charsetu, můžete se podělit v komentářích.

- Michal Jakoubě

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Tohle je nanic, SMPT adresa odesilatele je velmi casto padelana, staci tedy poslat spam v azbuce z domeny jine nez ru a nebo ua a jsi tam, kde jsi byl.... a spameri na to prijdou velice rychle. To chce proste komercni reseni typu IronPort, to jedine funguje a s ohromujici presnosti. Majkrosofti spam filtry proste nefunguji, jak by mely. Jak v outlooku, tak ve forefrontich produktech (osobni zkusenost)

  • Ale tim si odstrihl vlastni (Microsoft) domenu totineze.ru z Microsoftem nabizenych domen pro freemail (www.microsoft.com/.../coolhotmail). :-(

    Take mne SPAM zere, ale elegantni reseni neznam. Proste cas od casu nejaky prijde a pravidlo na nej neni, protoze se kryje s pravidlem, ktere naopak potrebujeme. Takova je proste doba. Bojovat a bojovat. Za to nas v IT zakaznik plati. Nejde neco nastavit a pak uz se tomu nevenovat.

  • Osobně jsem s antispamem v Exchange velmi spokojen. Většina problémů se spamem je buď v tom, že admin Exchange neumí antispam v Exchange správně nastavit, nebo právě tím, že je Exchange "schován" za nějakým "lepším" řešením a ztratí tak možnost využívat antispam agenty způsobem, jak jsou navrženi. Ale to je na složitější diskuzi... doporučuji se podívat sem, kde jsem o nastavení antispamuv Ex2010  psal: blogs.technet.com/.../exchange-server-2010-serial-nastaveni-antispamovych-funkci-cast-v.aspx

    Co se týká Forefront produktů, tak tam se jednoznačně jedná o jeden z nejlepších produktů na trhu. A nemusím rozjíždět flame, ale budu to dokazovat na 3 týdenním testu Virtus Bulletinu: www.pavlis.net/.../2402.aspx

    A ještě jedna poznámka - článek, který tu Michal sepsal je super. Není to nějaké pravidlo, které zachrání svět, nebo vaši firmu od spamu, ale je to spíš ukázka možností nastavení transportních pravidel v Exchange, který ve spojitosti s dalším nastavením může administrátorům pomoci a nebo je jen něco naučit nového, co třeba neznali...

  • Nějak jsem nepochopil tu zmínku o linuxu. Nejdřív si tam vedl úvahu o tom že ho vypneš. Pak jsi ho nechal zapnutý? Z vlastní zkušenosti vím, že největší procento spamů má podvrženou hlavičku tak, že se tváří, že pochází z mé domény. Proto jsem nastavil, že email z mé domény, pokud nepříjde z mých serverů tak ho odmítnu. To se dá nastavit velice jednoduše na MS Exchange i na Linuxu. Na mé doméně (cca 130000 emailů denně) má toto pravidlo účinnost cca 80 - 90%. Zbytek řeším jinak.

  • Jenže zapomínáte na pár věcí :

    1. ne všechny firmy si mohou dovolit blokovat doménu RU - oni prostě s rusky mluvícími zeměmi potřebují dnes a denně komunikovat

    2. forefront pro exchange hází do koše naprosto nevinné maily, kde není ani hypertextový odkaz, prostě jen jedna česká věta a on to prostě zahodí a nedá se to nijak ovlivnit

    3. narozdíl od konkurence typu IronPort si uživatel podezřelý spam nemůže nejak odblokovat a potřebuje k tomu admina, natož pak aby se ten produkt nějak učil.... prostě bída. Takže jeden z nejlepších produktů na trhu ? To tedy ani omylem, protože konkurence je tomuhle na míle vzdálená

    4. blacklisty dnes již kromě forefrontu skoro nikdo nepoužívá, jsou jiné lepší praktiky

    5. filtrace spamu v PDF a JPG opět nula - konkurence umí a dosti kvalitně, forefront zase opět nic

  • Bublifuk> Asi to nema smysl, asi chces bohuzel opravdu "jen" rozjet flame, nebo neznas aktualni Forefront Protection for Exchange a vychazis z nejake historicke zkusenosti... kazdopadne je skoda, ze sis ty odkazy neprohledl... budu reagovat jen na tvuj posledni bod 5. Cituji ze svého článku: "Forefront dosáhl výsledku přes 99% v mnoha oblastech, ale číslo 99.86% odhalující obrázkový spam je opravdu skvělé". Tolik za mě... :)

  • Mým záměrem s tímto článkem bylo naznačit, že častokrát administrátor nemůže hledět na daný problém pouze z jednoho pohledu a ani si nemůže jednoduše říci o další investici do antispamu, zkrátka musí řesit problém pomocí dostupných prostředků.

    Samozřejmě, že pokud bychom komunikovali s RU doménami (neznámými), tak zmíněný problém takto řešit nepůjde, ale to by nešlo, ani pokud by byla možnost filtrování na úrovni charsetu. V připadě potřeby jdou v transportních pravidlech dělat vyjímky, a proto případná komunikace s několika adresáty (doménami) není úplně vyloučena (pozn. pokud by nešly dělat vyjímky, tak stále filtrace probíhá přes regularní výraz a není problém upravit právě ten).

    Celé toto řešní funguje v malé organizaci se zhruba 100 uživateli a zatím jsem nezaznamenal jediný případ nežádoucího přesměrovaní.

  • Osobne nechapu proc ti ten SPAM nepochytal Forefront. Jedine co me napada ze mas mx2 nastaveno jako safe, coz v tvem pripade neni.

    Jinak pekna ukazka moznosti transportnich pravidel na Exchange serveru ale trochu hloupe nasazeni. Takhle se SPAM opravdu filtrovat nema.

  • u nas pouzivame velice easy skonfigurovany antispam kde 2 hlavne nastaveni jsou graylisting a reverse IP domain check + par veci kolem jako je reciepent check a podobne. uz jenom tyhle dve nastaveni mi odfiltrujou 99 % spamu, coz v nasem pripade byvalo kolem 1 - 2 Mil mail tydne a hlavni prinos je "popadani mail botu". za 3 roky provozu se spam znizil na 10 000/den coz je priblizne stejne jako mam "zdrave" posty. za tim.

    mementalni efektivita - 99,9 k 1 mailu za mesic false positive :) totaly free, skoseli sjem forefronta, firtinet, ironport, websense a nic nemelo takovou uspesnost jako tohle free reseni.

  • DObrý den. Prosím o radu. Používám MS exchange server, a to tak, že si synchronizuji Outlook a PDA a owa a zajímalo by mě, jestli je možné zajistit, když smažu mail v PDA (protože to mi slouží pouze informačně) aby zůstal na serveru a mohu s ním tedy dále pracovat v Outlooku. Teď když smažu jakoukoli položku, kterou mám nastavenou k synchronizaci v jakémkoli z ,,přístupových kanálů" položka je nadobro pryč (v PDA se mi při odstranění nepřesune do koše, ale rovnou se smaže. Doufám, že je můj dotaz srozumitelný a děkuji zapomoc.