Exchange 2003 virtuální SMTP servery

Určitě nejsem sám, kdo si ze začátku naivně myslel, že SMTP je přeci jednoduchý a pak při složitější architektuře a propojení více systémů proklíná záludnosti a úskalí tohoto protokolu. Dnes se na mne z konference obrátil jeden čtenář, zdali bych nerozvedl svůj stručný příspěvek. Času je málo, tak jsem se rozhodl zkopírovat lehce upravenou část dokumentace jednoho projektu. Nejde o step-by-step návod, spíš o zamyšlení, jak docílit korektní konfigurace. Z bezpečnostních důvodů byly pochopitelně určité části textu pozměněny, případně odstraněny.

Uvažujeme architekturu Exchange 2003 s webovou farmou front-end serveru a clusterem back-end serverů. Před těmito servery ještě stojí dvojice linuxových serverů, které jsou vstupními MTA pro příjem pošty z Internetu a provádí antivirovou a antispamovou kontrolu. Konfigurace Exchange serverů je krapet specifická, nevyužívá Recipient policies, ale technologii SMTP Domain Event Sink.

Před nastavením front-end serverů si je nutné uvědomit jejich roli a způsob toku zpráv, obzvláště SMTP. Front-end servery Exchange neumí být vstupním MTA, které by všechny příchozí maily přeposlalo na linuxový AV/AS. Tím je dáno, že vstupním MTA pro maily z Internetu musí být AV/AS. Tím zase vznikají další problémy:

- není doporučováno slučovat vstupní MTA a AV/AS, je riziko, že tyto servery budou úzkým hrdlem. Bude nutné nakonfigurovat monitoring na sledování zatížení serverů, v případě potřeby rozšiřovat počet serverů ve farmě.

- vstupní MTA by v dnešní době spamů mělo být schopno ověřovat existenci příjemce, pokud ne, s pomocí SMTP tar pitting zpozdit odpověď a přerušit příjem mailu. V každém případě však linuxovým serverům musíme předávat seznam inbound domén – na to využíváme připravený SMTP domain event sink textový soubor. Linuxy navíc kontrolují existenci příjemce vůči AD (LDAPu). Z toho vyplývá, že linuxy musí být i na back-end síti.

- vstupní MTA by měly využívat Connection Filtering s použitím RBL atd.

- pokud bychom chtěli nějak podporovat SPF a Sender ID vyhodnocování, musí to provádět vstupní MTA

- předřazené antiviry/antispamy mají nainstalován Postgrey s využitím tripletu Client_IP / Sender / Recipient (http://postgrey.schweikert.ch/)

Příchozí maily z Internetu tedy dopadnou na linuxový AV/AS, z Internetu dostupné jako dva MX záznamy určitých domén. Odtud se přeposílají profiltrované zprávy na virtuální SMTP server na webové farmě Exchange front-end serverů, který má pouze překládanou front-end IP adresu, tj. není dostupný z Internetu. Má zapnutý pouze a výhradně Anonymous access. Tento virtuální server se jmenuje Inbound SMTP Virtual Server. Tento virtuální SMTP server má odškrtlý checkbox „Allow all computers which successfully authenticate to relay, regardless of the list above.“ a seznam Computers je prázdný.

Na každém Exchange front-end serveru je založen také Outbound SMTP Virtual Server, který funguje jako Local bridgehead pro stávající routing group. Jedinou autentizací je Integrated Windows Authentication s fintou, že Permissions for Submit and Relay jsou prázdné.

http://www.microsoft.com/technet/technetmag/issues/2006/01/stopspam/

„There is a trick that allows you to remove authenticated submission and relaying, and yet still allow Exchange servers to communicate with each other. To do this, remove the default Authenticated Users group from the Permissions for Submit and Relay dialog box, leaving the Group or user names box empty (see Figure 4), and then click OK. Now Integrated Authentication access is allowed on the SMTP Virtual Server, but no user or group can actually use it. Only Exchange servers within the same organization can use it to communicate with each other.“

Tím se zabezpečí přihlášení a povolení Submit Permission pouze Exchange serverů (back-end i front-end). Specialitou tohoto typu virtuálního serveru je to, že nesdílí žádnou IP adresu v rámci NLBS. Naopak každý jednotlivý Exchange front-end server má tento server nastaven na svoji vlastní dedikovanou IP adresu z back-end sítě. Fail-over konfigurace je v tomto případě zajištěna uvedením tří virtuálních serverů coby Local Bridgehead serverů.

V případě, že autentikovaní uživatelé s IMAP4 či POP3 připojením pošlou e-mail přes Relay SMTP Virtual Server (viz níže), pošle to Relay server na Outbound server ze sdílené IP adresy v rámci NLBS (webové farmy).

Při odesílání pošty do Internetu přes Outbound SMTP Virtual Server je zdrojovou adresou primární adresa konkrétního fyzického uzlu NLBS webové farmy. Pro webovou farmu Exchange front-end serverů je proto na routeru zřízen PAT, tj. všechny 3 servery budou (pohledem Internetu) odesílat maily z jedné jediné IP adresy. Tato veřejná IP adresa je uvedena jako PTR v reverzní zóně, dále v SenderID TXT záznamu a pochopitelně A záznam ve veřejném DNS.

Posledním SMTP serverem je již zmíněný Relay SMTP Virtual Server. Slouží pro příjem odesílaných zpráv od povinně autentikovaných uživatelů. Tj. na tomto virtuálním SMTP serveru je povinně vyžadována Basic autentizace (Windows Integrated nemá v mnou popisovaném nasazení smysl). Toto je jediný SMTP server, na kterém má smysl mít SSL certifikát. Toto je zároveň také jediný virtuální SMTP server, který má nastaveno pro Authenticated Users právo Submit Permission a Relay Permission na Allow. Tento virtuální SMTP server má odškrtlý checkbox „Allow all computers which successfully authenticate to relay, regardless of the list above.“ a seznam Computers je prázdný.

Níže uvedené platí pro speciální instalace Exchange serveru pro hostovaná nasazení.

Vzhledem k nějakému bugu v Exchange Serveru (možná způsobil nějaký hotfix, nyní není známo), se v případě odškrtnutí checkboxu Anonymous access na Relay SMTP Virtual Serveru nepodaří lidem s POP a IMAP přístupem odeslat přes tento SMTP server poštu do Internetu, ačkoliv zde se píše opak.. Při připojení se jim objeví jedna z těchto chybových hlášek:

The message could not be sent. The authentication setting might not be correct for your outgoing e-mail [SMTP] server. For help solving this problem, go to Help, search for "Troubleshoot Windows Mail", and read the "I'm having problems sending e-mail" section. If you need help determining the proper server settings, please contact your e-mail service provider.

The rejected e-mail address was '*********@***********.cz'. Subject 'zoufalypokus', Account: 'imap4.******.cz', Server: 'smtp.*******.cz', Protocol: SMTP, Server Response: '454 5.7.3 Client does not have permission to submit mail to this server.', Port: 25, Secure(SSL): No, Server Error: 454, Error Number: 0x800CCC78

nebo

The rejected e-mail address was '********@**********.cz'. Subject 'zoufalypokus', Account: 'imap4.******.cz', Server: 'smtp.*******.cz', Protocol: SMTP, Server Response: '454 5.7.3 Client does not have permission to Send As this sender.', Port: 25, Secure(SSL): No, Server Error: 454, Error Number: 0x800CCC78

Proto jsem zapnul na Relay SMTP Virtual Serveru Anonymous access a pomocí bind/unbind VBS skriptu přiloženého u SMTP Event Sink instalace jsem „odbindoval“ SMTP Domain Event Sink u Default SMTP Virtual Server (zastavený, standardně vytvářený SMTP virtual server), Inbound SMTP Virtual Server (nechci zatěžovat server kontrolou domény, která již byla jednou provedena na předřazených AV/AS), Outbound SMTP Virtual Server (nemá smysl kontrolovat domény u odchozí pošty). Díky tomuto nastavení je sice můj SMTP virtuální server, určený pro relaying, dostupný z Internetu, ale nepovolí žádný relay ani submit s výjimkou korektně přihlášených uživatelů.

V případě, že bych měl standardní (nikoliv hostovanou) Exchange, jež využívá standardní princip Recipient Policies, je žádoucí u Relay SMTP Virtual Serveru vypnout Anonymous access, vypnout samozřejmě i Integrated Windows Authentication a ponechat zaškrtlou pouze Basic authentication. Je více než moudré v nastavení SSL povinně vyžadovat 128-bitové šifrování.