Bezpieczne protokoły e-mail, tajemniczy spam i więcej

Opublikowano: 24 stycznia 2008

Zawartość strony

	Pyt. Chcę zastosować bezpieczny protokół SMTP. Jak sprawić, żeby program Exchange Server nasłuchiwał SMTP przez port 465?
	Pyt. Mam dużą liczbę wiadomości e-mail w kolejce do kilku domen, a żaden z moich użytkowników nie wysyłał żadnych wiadomości. Co się dzieje i jak temu zapobiec?
	Pyt. Do tej pory moja firma korzystała z jednego serwera z Exchange Server 2000 oraz drugiego z Exchange Server 2003, przy czym każdy z nich z wysyłał pocztę do sieci internetowej. Po zainstalowaniu wersji 2007 skrzynki pocztowe przestały wysyłać pocztę.
	Pyt. Dlaczego otrzymuję kilka raportów dziennika dla tej samej wiadomości w programie Exchange Server 2007?
	Pyt. Co się stało z opcją przesyłania dalej do hosta nierozpoznanych wiadomości w programie Exchange Server 2007?
	Pyt. Próbuję przygotować moją domenę główną do instalacji programu Exchange Server 2007. Serwer z Exchange Server 2007, posiada zainstalowanego Menedżera systemu Exchange (ESM) programu Exchange Server 2003 i instalacja nie udaje się.
	Pyt. Kiedy pojawi się możliwość uruchomienia narzędzi zarządzania programu Exchange Server 2007 na stacji roboczej z zainstalowanym systemem Windows Vista?
	Pyt. A co z menedżerem ESM programu Exchange Server 2003 w systemie Windows Vista lub Windows Server 2008? Czy on też będzie obsługiwany przez te systemy?
	Pyt. Mam w swojej domenie kilka serwerów z zainstalowanym programem Exchange Server 2003. Czy mogę aktualizować swoje kontrolery domeny do kontrolerów domeny systemu Windows Server 2008?

Pyt. Chcę zastosować bezpieczny protokół SMTP. Jak sprawić, żeby program Exchange Server nasłuchiwał SMTP przez port 465?

Odp. Obawiam się, że to nie jest możliwe. Można sprawić, że wirtualny serwer SMPT lub łącznik Receive będzie nasłuchiwać na porcie 465, jednak nie zostanie osiągnięty założony cel – bezpieczny protokół SMTP (SMTPS).

Dlaczego? Zobaczmy. Istnieją dwa typy protokołu SSL: jawny oraz niejawny. Początkowo większość protokołów SSL była niejawna. Oznaczało to, że stosowany był dedykowany port dla protokołu SSL. Przykładowo protokół HTTP znajduje się domyślnie na porcie 80, a HTTPS (HTTP z SSL) na porcie 443. Kilka lat temu wspólnota internetowa zdecydowała, że port dedykowany nie będzie wymagany dla protokołu SSL. W ten sposób powstał jawny protokół SSL.

W programie Netscape wybrano już port 465 jako port SMTPS, jednak program Exchange Server nie posiadał żadnej funkcjonalności SLL w protokole SMTP. Zespół pracujący nad programem Exchange dostrzegł przewagę jawnego protokołu SSL – mianowicie, że może być on używany zarówno przez klienty, jak i serwery – i zdecydował się zastosować obsługę jawnego protokołu SLL dla protokołu SMTP.

W przypadku SMTP jawny protokół SSL wykorzystuje polecenie STARTTLS ESMTP w celu zakomunikowania, że istniejące gniazdo ma zostać zabezpieczone. Większość pozostałych sprzedawców, serwerów i klientów SMTP zastosowało polecenie STARTTLS, więc tak naprawdę nigdy nie było większej potrzeby obsługiwania portu 465, który i tak nie był oficjalnym standardem internetowym.

Jak do tej pory, żadna wersja programu Exchange Server nie obsługuje niejawnego protokołu SSL dla połączenia SMTP. Nie zmieni tego faktu polecenie nasłuchiwania na porcie 465 skierowane do złącza Receiver programu Exchange lub do wirtualnego serwera SMTP. Dlatego też konieczne jest zastosowanie klienta obsługującego polecenie STARTTLS na porcie 25. Jeżeli zastosowanie portu 25 nie jest możliwe, następnym logicznym rozwiązaniem jest port 587, będący standardowym portem dla przesyłania pakietów serwerów klienckich SMTP. Obecnie nie ma zbyt wielu współczesnych klientów, które nie obsługują polecenia STARTTLS na porcie 25, zatem dodawanie obsługi dla niejawnego protokołu SSL nie było konieczne.

Tak przy okazji, protokoły POP3 oraz IMAP4 programu Exchange zawsze obsługiwały niejawny protokół SSL. Jednak w programie Exchange Server 2007 została dodana obsługa jawnego protokołu SSL dla tych protokołów. Jednak z uwagi na fakt, iż niewiele klientów obsługuje ten nowszy standard, niejawny protokół SSL będzie dostępny jeszcze przez jakiś czas.

Pyt. Mam dużą liczbę wiadomości e-mail w kolejce do kilku domen, a żaden z moich użytkowników nie wysyłał żadnych wiadomości. Co się dzieje i jak temu zapobiec?

**Odp.**Ten problem jest często spotykany. Każdy, kto posiada serwer w Internecie, może spotkać się z tym problemem. Zasadniczo może on mieć dwie przyczyny. Pierwszą z nich mogło być przypadkowe umożliwienie przekazywania (patrz: support.microsoft.com/kb/304897). Ale przecież tak się nie stało, prawda? (Serwery Open relay nie są stosowane już od czasu Exchange Server 2000.) Bardziej prawdopodobne jest, że mamy do czynienia ze spamem powstałym z raportów o niedostarczeniu (NDR).

Rozsyłając swoje wiadomości, spamerzy często używają adresów nieistniejących w domenie. Serwer próbuje poinformować tę osobę, że tacy użytkownicy nie istnieją, ale oczywiście adres powrotny jest sfałszowany. Osoba wysyłająca spam może podszywać się pod nieistniejący adres (w takim przypadku raport NDR „wisi” przez chwilę, po czym traci ważność) lub może spróbować sprawić, aby nasz serwer w swoim imieniu wysłał do innej domeny spam w postaci załącznika do wygenerowanego przez siebie raportu NDR.

Istnieje możliwość wyłączenia raportów NDR. Jednak jeżeli wtedy prawdziwy użytkownik przez pomyłkę zrobi błąd w adresie, serwer nigdy go nie poinformuje, że wiadomość nie została wysłana. W ten sposób ważne wiadomości mogą zaginąć.

Oto lepsze rozwiązanie: Po pierwsze należy się upewnić, że nasz serwer nie jest typu „open relay”. Następnie należy włączyć jakiś filtr antyspamowy – taki, jak inteligentny filtr wiadomości (IMF) lub filtr zawartości programu Exchange Server – jak również kilka list blokowania w czasie rzeczywistym (RBL). Można to zrobić zarówno w roli Edge Transport, jak i Hub Transport, ale powinno to się odbyć w pierwszej kolejności. Dlatego, że zwykle ponad 90 proc. wszystkich wiadomości e-mail to spam, a nie chcemy przecież, żeby nasze serwery traciły czas na zajmowanie się spamem.

Na koniec należy włączyć filtrowanie adresatów na pierwszym serwerze Exchange, który akceptuje pocztę przychodzącą do środowiska. To umożliwia serwerowi odrzucenie wiadomości, zanim dotrze ona do naszej sieci. Wiadomości z błędnym adresem będą powodować wygenerowanie raportu NDR, ale będzie on generowany przez serwer osoby wysyłającej.

Pyt. Do tej pory moja firma korzystała z jednego serwera z Exchange Server 2000 oraz drugiego z Exchange Server 2003, przy czym każdy z nich z wysyłał pocztę do sieci internetowej. Po zainstalowaniu wersji 2007 skrzynki pocztowe przestały wysyłać pocztę.

Odp. Jeżeli w przeszłości w firmie zainstalowany był tylko jeden program Exchange Server, idea łączników może nie być dobrze znana. Łączniki programu Exchange są obiektami logicznej konfiguracji routingu, informującymi program Exchange, gdzie ma być skierowana poczta. Po wprowadzeniu Exchange Serwer 2007 w istniejącej organizacji, aby móc routować pocztę, konieczne jest posiadanie łączników grup routingu oraz łącznika SMTP.

Potrzebne będą dwa złącza grup routingu – jedno wychodzące od grupy routingu programu Exchange Server 2007 do grupy routingu programu Exchange Server 2003, drugie odwrotnie. Można to ustawić jako część procesu instalacji. Jeżeli jednak nie zostało to załatwione w trakcie instalacji lub nie ma co do tego pewności, można to sprawdzić za pomocą powłoki Exchange Management Shell i tam naprawić problem. Jeśli tak się nie stanie, nie będzie możliwości wysyłania poczty pomiędzy tymi dwoma serwerami. Wiadomości utkną w niedostępnych kolejkach.

Aby móc routować pocztę elektroniczną, wystarczy jeden łącznik SMPT, zwany także łącznikiem Send w programie Exchange Server 2007. Łącznik ten powinien być dostępny w programie Exchange Server 2000 oraz Exchange Server 2003, ale wcale nie musi. Przestrzeń adresowa dla wszystkich domen powinna mieć format SMTP:*, przy czym możliwe jest wykorzystanie do odbierania poczty inteligentnego hosta lub serwera DNS. Istnieje możliwość wyboru, czy wychodząca poczta internetowa ma być obsługiwana przez program Exchange Server 2007, czy przez starszy serwer. Można utworzyć jeden łącznik w obydwu grupach routingu, jeżeli potrzeba, aby każdy serwer obsługiwał własną pocztę. Można także utworzyć jeden łącznik jako część procesu Edgesync w przypadku zainstalowania roli serwera Edge Transport.

Jeżeli poprzednio inteligentny host został umieszczony na wirtualnym serwerze SMTP, teraz jest dobry moment na jego usunięcie. Powinien on znajdować się wyłącznie na złączu SMTP, a nie na wirtualnym serwerze, ponieważ spowoduje to problem ze złączem grup routingu.

Należy także mieć świadomość, że poczta przychodząca jest kontrolowana przez rekord MX lub adres IP, na który przekazuje ją zapora internetowa. Po stronie programu Exchange nie ma zbyt wielu opcji konfiguracji, ale w przypadku dalszych problemów pomocny powinien być następujący dokument: msexchangeteam.com/archive/2006/11/17/431555.aspx (j.ang.).

Pyt. Dlaczego otrzymuję kilka raportów dziennika dla tej samej wiadomości w programie Exchange Server 2007?

Odp. Agent rejestrowania w dzienniku w programie Exchange Server 2007 rejestruje w dzienniku wiadomości po ich kategoryzacji. Kategoryzator ma wiele powodów, dla których rozdziela wiadomość (czyli kopiuje treść wiadomości i umieszcza różnych odbiorców kopertowych na różnych kopiach). Oto przykład: Obecnie rejestrowanie w dzienniku zapewnia dostęp do informacji o uczestnikach grupy dystrybucyjnej w momencie wysłania wiadomości, więc sytuacja, w której możliwe jest otrzymanie wielu raportów, ma miejsce w przypadku zagnieżdżonej grupy dystrybucyjnej.

Ta dodatkowa liczba raportów oznacza, że możemy otrzymać kilka kopii tej samej wiadomości, każdą z oddzielnym raportem. Nie ma pewnego sposobu na sprawdzenie, czy wszystkie raporty danej wiadomości dotarły pod odpowiedni adres, ale jeżeli dokonywana jest archiwizacja, może zajść potrzeba skontaktowania się z dostawcą archiwum w celu upewnienia się, że jest on świadomy zmian.

Pyt. Co się stało z opcją przesyłania dalej do hosta nierozpoznanych wiadomości w programie Exchange Server 2007?

Odp. Wyparowała.

Tak naprawdę ta opcja nigdy się nie sprawdzała w sytuacji, w której zainstalowany był więcej niż jeden program Exchange Server. Exchange już wcześniej posiadał rozwiązanie dotyczące nierozpoznanych wiadomości, przy czym ta metoda była o wiele bardziej złożona. Dokładniej mówiąc, chodzi tu o możliwość udostępniania indywidualnych domen SMTP innym systemom. Zatem opcja „przekaż dalej nierozpoznane” została usunięta, a koncepcja domen udostępnionych została uproszczona. W programie Exchange Server 2007: przejdź do menu Organizacja |Transport centralny| Akceptowane domeny i zmień typ domeny z autorytatywnej na wewnętrzny przekaźnik. W przypadku niektórych środowisk jest to trochę bardziej skomplikowane, więc cały czas pracujemy nad aktualizacją dokumentacji. To powinno jednak pomóc.

Pyt. Próbuję przygotować moją domenę główną do instalacji programu Exchange Server 2007. Serwer z Exchange Server 2007, posiada zainstalowanego Menedżera systemu Exchange (ESM) programu Exchange Server 2003 i instalacja nie udaje się.

Odp. Mówiąc po prostu, instalacja jakiejkolwiek części programu Exchange Server 2007 na serwerze posiadającym zainstalowane dowolne komponenty programu Exchange Server 2000 lub 2003 nie jest obsługiwana. Ponieważ zainstalowany jest menedżer ESM programu Exchange Server 2003, instalacja programu Exchange Server 2007 go wykryje i wstępne przygotowanie instalacji nie uda się. Program wyświetli wówczas komunikat: „Na tym komputerze zainstalowana jest poprzednia wersja programu Exchange Server. Uruchom instalator programu Exchange Server 2007 z innego komputera lub usuń poprzednią wersję programu Exchange Server”.

Prawdopodobnie najprostszym sposobem obejścia tego problemu jest uruchomienie instalacji programu Exchange Server 2007 z innego serwera w domenie głównej i przygotowanie domeny w ten sposób. Jeżeli to jest niewykonalne, komponent programu Exchange Server 2003 będzie musiał zostać odinstalowany przed kontynuowaniem instalacji programu Exchange Server 2007.

Należy pamiętać, że do przygotowania domeny można zastosować 32-bitową wersję programu Exchange Server 2007, zatem każdy 32-bitowy serwer w domenie głównej będzie wystarczający. Więcej informacji na ten temat: http://www.technet.microsoft.com/library/bb232170.aspx (j.ang.).

Oznacza to, że nie ma możliwości zainstalowania menedżera ESM programu Exchange Server 2003 oraz konsoli zarządzania programu Exchange Server 2007 na tej samej maszynie, ponieważ takie współistnienie narzędzi zarządzania programów Exchange Server 2003 oraz Exchange Server 2007 nie jest obsługiwane. Powtarzam: program Exchange Server 2007 zablokuje instalację przy próbie jego zainstalowania na maszynie posiadającej zainstalowane jakiekolwiek elementy programu Exchange Server 2000 lub Exchange Server 2003.

Na koniec zauważmy, że nie należy próbować najpierw zainstalować narzędzi zarządzania programu Exchange Server 2007, a potem narzędzi programu Exchange Server 2003 na tej samej maszynie. Takie podejście może spowodować konfigurację, która nie została przetestowana i może spowodować wystąpienie nieoczekiwanych problemów podczas próby zarządzania serwerami. Jeżeli jest potrzeba zarządzania obydwoma wersjami programu na jednej maszynie, można zastosować zdalny komputer biurowy do połączenia z jedną wersją, lub zastosować wirtualną maszynę obsługującą różne wersje narzędzi zarządzania w środowisku odizolowanym.

Pyt. Kiedy pojawi się możliwość uruchomienia narzędzi zarządzania programu Exchange Server 2007 na stacji roboczej z zainstalowanym systemem Windows Vista?

**Odp.**Obsługa narzędzi zarządzania programu Exchange Server 2007 przez system Windows Vista będzie możliwa w momencie ukazania się dodatku Service Pack 1 do Exchange Server 2007. Pakiet zawierający narzędzia zarządzania dodatku Exchange Server 2007 SP1 będzie dostępny do pobrania po ukazaniu się Service Pack 1.

Pyt. A co z menedżerem ESM programu Exchange Server 2003 w systemie Windows Vista lub Windows Server 2008? Czy on też będzie obsługiwany przez te systemy?

**Odp.**Tak niestety nie będzie. Narzędzia zarządzania dla jakiejkolwiek wersji programu Exchange Server starszej niż Exchange Server 2007 z dodatkiem SP1 nie będą obsługiwane przez system Windows Vista ani Windows Server 2008. To oznacza, że nawet po wprowadzeniu wersji Windows Server 2008, zainstalowanie menedżera ESM programu Exchange Server 2003 nie będzie możliwe. Zarządzanie serwerami z zainstalowanym programem Exchange Server 2003 będzie musiało odbywać się za pomocą stacji roboczych z systemem Windows Server 2003 lub Windows XP; alternatywnie możliwe jest także zastosowanie połączenia pulpitu zdalnego z dowolnego systemu operacyjnego.

Pyt. Mam w swojej domenie kilka serwerów z zainstalowanym programem Exchange Server 2003. Czy mogę aktualizować swoje kontrolery domeny do kontrolerów domeny systemu Windows Server 2008?

Odp. Korzystanie z programu Exchange Server 2003 z dodatkiem SP2 w domenie posiadającej kontrolery domeny systemu Windows Server 2008 jest możliwe. Należy jednak zauważyć, że program Exchange Server nie może wykorzystywać kontrolerów domeny tylko do odczytu (RODC) ani serwerów wykazu globalnego tylko do odczytu (ROGC). Ręczne wymuszenie stosowania RODC/ROGC systemu Windows Server 2008 przez program Exchange Server może skutkować nieoczekiwanym zachowaniem.

  Do początku strony