TechNet Magazine > Home > Alle Ausgaben > 2007 > November >  Exchange Fragen & Antworten: Sichere E-Mail...
Exchange Fragen & Antworten Sichere E-Mail-Protokolle, rätselhaftes Spam und mehr
Nino Bilic and Scott Landry

Dieser Artikel basiert auf einer Vorabversion von Windows Server 2008. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

F: Ich möchte sicheres SMTP verwenden. Wie erreiche ich, dass Exchange Server SMTP auf Port 465 abhört?
A: Leider ist dies nicht möglich. Sie können zwar erreichen, dass ein virtueller SMTP-Server oder ein Empfangsconnector auf Port 465 abhört, doch damit erzielen Sie kein sicheres SMTP (SMTPS).
Warum? Dafür muss etwas weiter ausgeholt werden. Es gibt zwei Arten von SSL: explizit und implizit. Am Anfang handelte es sich bei SSL in den meisten Fällen um den impliziten Typ, das heißt, dass für SSL ein dedizierter Port verwendet wurde. Zum Beispiel befindet sich HTTP standardmäßig auf Port 80, doch HTTPS (HTTP mit SSL) befindet sich auf Port 443. Vor mehreren Jahren hat sich die Internetcommunity dafür ausgesprochen, dass für SSL kein dedizierter Port erforderlich sein soll. So entstand der explizite SSL-Typ.
Netscape hatte bereits 465 als SMTPS-Port gewählt, doch Exchange Server enthielt keine SSL-Funktionalität in SMTP. Das Exchange-Team sah jedoch die Vorteile des expliziten SSL (dass es sowohl von Clients als auch von Servern genutzt werden kann) und entschied sich, das explizite SSL für SMTP zu unterstützen.
Im Fall des SMTP verwendet das explizite SSL den STARTTLS ESMTP-Befehl, um zu signalisieren, dass der vorhandene Socket gerade gesichert wird. Die Mehrzahl der anderen Hersteller von SMTP-Servern und -Clients haben den STARTTLS-Befehl ebenfalls implementiert, sodass kein Grund bestand, Port 465 zu unterstützen, der ja keinen offiziellen Internetstandard darstellte.
Bislang wird das implizite SSL für SMTP von keiner Exchange Server-Version unterstützt. Dem Exchange-Empfangsconnector oder dem virtuellen SMTP-Server die Anweisung zu geben, auf Port 465 abzuhören, ändert nichts an dieser Tatsache. Deshalb müssen Sie einen Client verwenden, der STARTTLS auf Port 25 unterstützt. Wenn Sie Port 25 nicht verwenden können, ist die nächste logische Auswahl 587 – der Standardport für Client-SMTP-Übermittlungen. Es gibt nicht viele moderne Clients, die STARTTLS auf 25 nicht unterstützen. Also gab es keinen Bedarf, die Unterstützung für implizites SSL hinzuzufügen.
Nebenbei bemerkt haben die Exchange POP3- und IMAP4-Protokolle immer implizites SSL unterstützt. Doch in Exchange Server 2007 ist jetzt auch für diese beiden Protokolle zusätzliche Unterstützung für explizites SSL enthalten. Da viele Clients diesen neueren Standard noch nicht unterstützen, wird implizites SSL soweit absehbar weiterhin verfügbar sein.

F: Ich habe eine große Anzahl von E-Mails, die sich in der Warteschlange für eine Reihe von Domänen befinden. Doch keine dieser E-Mails stammt von meinen Benutzern. Was geschieht hier, und wie verhindere ich es?
A: Das ist ein allgemeines Problem. Alle, die über einen Server auf dem Internet verfügen, können mit diesem Problem konfrontiert werden. Grundsätzlich gibt es zwei mögliche Ursachen. Die erste ist, dass Sie Relay (siehe support.microsoft.com/kb/304897) ermöglicht haben. Das ist eher nicht anzunehmen. (Offene Relays sind seit Exchange Server 2000 standardmäßig deaktiviert.) Es ist also wahrscheinlicher, dass es sich hier um NDR-Spam (Unzustellbarkeitsbericht, non-delivery report) handelt. Beim Senden von Junk-E-Mails senden Spammer oftmals an nicht vorhandene Adressen in Ihrer Domäne. Ihr Server versucht, dem Spammer mitzuteilen, dass die Benutzer nicht existieren, doch natürlich hat der Spammer die Absenderadresse manipuliert. Es kann sein, dass der Spammer eine ungültige Adresse verwendet (in diesem Fall wird der NDR eine Zeit lang blockiert, bis die Zeit abgelaufen ist) oder dass er versucht, Ihren Server dazu zu bringen, in seinem Namen Spam an eine andere Domäne zu senden, und zwar als Anlage des Unzustellbarkeitsberichts, den Ihr Server generiert hat.
Sie könnten NDRs deaktivieren, doch wenn ein legitimer Benutzer sich bei einer Adresse versehentlich vertippt, wird Ihr Server keine Benachrichtigung senden, dass die E-Mail nicht empfangen wurde, und wichtige Nachrichten könnten so verloren gehen. Hier ist eine bessere Lösung.
Stellen Sie als Erstes sicher, dass Relay nicht möglich ist. (Soll hier einfach noch einmal erwähnt werden.) Aktivieren Sie als Nächstes eine Art von Antispamfilterung, zum Beispiel den intelligenten Nachrichtenfilter (intelligent message filter, IMF) oder den Exchange Server 2007-Inhaltsfilter sowie einige Echtzeit-Sperrlisten (Realtime Block Lists, RBLs). Dies kann in der Edge-Transport-Funktion oder der Hub-Transport-Funktion erfolgen, sollte jedoch beim allerersten Hop geschehen, da es sich bei 90 Prozent aller E-Mails in der Regel um Spam handelt und es nicht wünschenswert ist, die Server damit zu belasten.
Aktivieren Sie schließlich die Empfängerfilterung für den ersten Exchange Server, der die E-Mails in Ihrer Umgebung annimmt. Dies ermöglicht Ihrem Server, eine Nachricht abzulehnen, bevor sie in Ihr Netzwerk gelangt. Bei Tippfehlern in legitimen Adressen wird nach wie vor ein NDR gesendet, doch dieser Unzustellbarkeitsbericht wird vom Server des Absenders generiert.

F: Ich habe einen Server unter Exchange Server 2000 ausführen lassen und einen unter Exchange Server 2003, und beide sendeten erfolgreich E-Mails an das Internet. Dann habe ich Exchange Server 2007 installiert, und jetzt können die Postfächer auf beiden Servern keine E-Mails mehr senden.
A: Wenn Sie früher nur einen Exchange Server hatten, sind Sie möglicherweise nicht ausreichend mit dem Konzept der Connectors vertraut. Exchange-Connectors sind logische Routerkonfigurationsobjekte, die Exchange mitteilen, wo die E-Mail hingeleitet werden soll. Wenn Sie Exchange Server 2007 in einer bestehenden Organisation einführen, um E-Mails weiterzuleiten, müssen Sie unbedingt über Routinggruppenconnectors und einen SMTP-Connector verfügen.
Sie werden zwei Routinggruppenconnectors benötigen: einen von der Exchange Server 2007-Routinggruppe zum Exchange Server 2003-Routinggruppe sowie umgekehrt. Sie können dies als Teil des Installationsvorgangs festlegen, aber wenn Sie dies versäumt haben oder sich nicht sicher sind, können Sie es anhand der Exchange-Verwaltungsshell überprüfen und dort das Problem korrigieren. Andernfalls werden Sie zwischen Ihren Servern keine E-Mails senden können. Die Nachrichten landen dann in unzugänglichen Zielwarteschlangen.
Um Internet-E-Mails weiterzuleiten, benötigen Sie nur einen einzigen SMTP-Connector, der in Exchange Server 2007 auch als Sendeconnector bekannt ist. Es sollte einer in Exchange Server 2000 und einer in Exchange Server 2003 vorhanden sein, doch möglicherweise sind Sie ohne einen ausgekommen. Der Adressraum sollte für alle Domänen „SMTP:*“ sein. Sie können festlegen, ob ein Smarthost oder DNS für das Zustellen von E-Mails verwendet werden soll. Sie wählen aus, ob ausgehende Internet-E-Mails vom Exchange Server 2007-Server oder vom älteren Server behandelt werden sollen, oder Sie können für beide Routinggruppen einen erstellen, wenn Sie möchten, dass jeder Server seine eigenen E-Mails behandelt. Sie können außerdem einen davon als Teil des Edgesync-Prozesses erstellen, wenn Sie eine Edge-Transport-Serverfunktion installiert haben.
Wenn Sie zuvor einen Smarthost auf den virtuellen SMTP-Server gestellt haben, ist jetzt eine guter Zeitpunkt, um ihn zu entfernen. Er sollte sich nur auf dem SMTP-Connector und in keinem Fall auf dem virtuellen Server befinden, da dadurch der Routinggruppenconnector unterbrochen wird.
Sie sollten außerdem daran denken, dass eingehende E-Mails von Ihrem MX-Datensatz oder dem IP gesteuert werden, an den bzw. das die Firewall weiterleitet. Was Exchange angeht, gibt es nicht viel zu konfigurieren, doch dieses Dokument dürfte Ihnen helfen, falls Sie immer noch Schwierigkeiten haben: msexchangeteam.com/archive/2006/11/17/431555.aspx.

F: Warum erhalte ich mehrere Journalberichte für dieselbe Nachricht in Exchange Server 2007?
A: Der Journal-Agent des Exchange Server 2007-Transports erfasst die Nachrichten nach ihrer Einstufung. Das Kategorisierungsmodul hat viele Gründe, warum es eine Nachricht teilt (d. h. den Nachrichtentext kopiert und die jeweiligen Umschlagsempfänger auf die jeweiligen Kopien setzt). Hier ist ein Beispiel: Da die Journalfunktion jetzt die Fähigkeit hat, Ihnen mitzuteilen, welche Mitgliedschaft eine Verteilergruppe zur Absendezeit der Nachricht hatte, könnten Sie zum Beispiel für eine verschachtelte Verteilergruppe mehrere Berichte abrufen.
Diese zusätzliche Funktion in der Berichterstattung bedeutet, dass Sie mehrere Kopien derselben Nachricht, jeweils mit einem speziellen Bericht, erhalten können. Es gibt keine Möglichkeit, um mit Sicherheit zu wissen, ob alle Berichte für eine Nachricht angekommen sind, doch wenn Sie archivieren, werden Sie sicher gemeinsam mit dem Hersteller des Archivs sicherstellen wollen, dass die Änderungen berücksichtigt werden.

F: Was ist mit dem Feature in Exchange Server 2007 zum Weiterleiten nicht aufgelöster Nachrichten an den Host geschehen? What do I do now?
A: Dieses Feature gibt es nicht mehr.
Genau genommen hat es in Situationen mit mehr als einem Exchange Server nie so richtig gut funktioniert. Exchange hat allerdings dasselbe bereits auf eine andere, viel leistungsfähigere Weise erreicht. Sie haben vor allem die Möglichkeit, einzelne SMTP-Domänen mit anderen Systemen gemeinsam zu verwenden. Deshalb wurde das Feature für das Weiterleiten nicht aufgelöster Nachrichten aufgegeben, und das Konzept der freigegebenen Domäne wurde fortgesetzt und vereinfacht. Gehen Sie in Exchange Server 2007 zu „Organisation“ | „Hub-Transport“ | „Akzeptierte Domänen“, und ändern Sie den Domänentyp von „Autorisierend“ in „Internes Relay“. Für manche Umgebungen ist es nicht ganz so einfach wie hier geschildert, und es wird daran gearbeitet, die jeweiligen Abschnitte der Dokumentation zu aktualisieren. Doch in der Zwischenzeit dürfte dies eine Hilfe sein.

F: Ich versuche, meine Stammdomäne für die Exchange Server 2007-Installation vorzubereiten. Auf dem Server, von dem aus ich versuche, das Exchange Server 2007-Setup auszuführen, ist Exchange Server 2003 ESM (Exchange-System-Manager) installiert, und die Installation schlägt fehl. Wo liegt hier das Problem?
A: Kurz gesagt wird das Ausführen des Exchange Server 2007-Setup auf einem Computer, auf dem Exchange Server 2000- oder 2003-Komponenten installiert sind, nicht unterstützt. Da Exchange Server 2003 ESM installiert ist, wird dies vom Exchange Server 2007-Setup erkannt, sodass die Überprüfung der Setupvoraussetzungen mit der Fehlermeldung endet, dass eine frühere Version von Exchange Server bereits auf diesem Computer installiert ist. Führen Sie das Exchange Server 2007-Setup von einem anderen Computer aus, oder entfernen Sie die frühere Version von Exchange Server.
Am einfachsten umgehen Sie dieses Problem wahrscheinlich, indem Sie das Exchange Server 2007-Setup einfach von einem anderen Server in der Stammdomäne aus ausführen und Ihre Domäne auf diese Weise vorbereiten. Wenn das nicht durchführbar ist, muss die Exchange Server 2003-Komponente deinstalliert werden, bevor Sie das Exchange Server 2007-Setup fortsetzen können.
Denken Sie daran, dass Sie die 32-Bit-Version von Exchange Server 2007 verwenden können, um die Domäne vorzubereiten. Es kann also in der Regel jeder 32-Bit-Server in der Stammdomäne verwendet werden. Weitere Informationen zu diesem Thema erhalten Sie unter „technet.microsoft.com/library/bb232170.aspx“.
Das heißt übrigens, dass Sie Exchange Server 2003 ESM und die Exchange Server 2007-Exchange-Verwaltungskonsole nicht auf dem gleichen Computer installieren können, da das gleichzeitig Vorhandensein der Exchange Server 2003- und der Exchange Server 2007-Verwaltungstools auf dem gleichen Computer nicht unterstützt wird. Exchange Server 2007 blockiert das Setup, wenn Sie versuchen, es auf einem Computer zu installieren, auf dem eine Exchange Server 2000- oder Exchange Server 2003-Komponente installiert ist.
Abschließend soll darauf hingewiesen werden, dass Sie nicht versuchen sollten, zuerst die Exchange Server 2007-Verwaltungstools zu installieren und dann mit der Installation der Exchange Server 2003-Tools auf dem gleichen Computer fortzufahren. Mit diesem Ansatz erhalten Sie eine Konfiguration, die nicht getestet wurde und die beim Verwalten Ihrer Server zu unerwarteten Ergebnissen führen kann. Wenn Sie beide Serverversionen von einem einzigen Computer verwalten müssen, könnten Sie Remotedesktop verwenden, um eine Verbindung zu einer Version herzustellen, oder Sie könnten einen virtuellen Computer verwenden, um eine andere Version der Verwaltungstools in einer isolierten Umgebung zu hosten.

F: Wann wird es endlich möglich sein, die Exchange Server 2007-Verwaltungstools auf einer Windows Vista®-Arbeitsstation auszuführen?
A: Die offizielle Unterstützung für die Exchange Server 2007-Verwaltungstools unter Windows Vista wird mit der Veröffentlichung von Exchange Server 2007 SP1 eingeführt. Sobald Exchange Server 2007 SP1 veröffentlicht ist, wird ein Paket mit den Exchange Server 2007 SP1-Verwaltungstools zum Herunterladen verfügbar sein.

F: Was ist mit Exchange Server 2003 ESM unter Windows Vista oder Windows Server 2008? Werde ich es auch ausführen können?
A: Nein, das wird leider nicht möglich sein. Die Verwaltungstools für alle Versionen von Exchange Server vor Exchange Server 2007 SP1 wird weder unter Windows Vista noch unter Windows Server 2008 unterstützt. Das heißt, dass auch nach der Veröffentlichung von Windows Server 2008 das Installieren von Exchange Server 2003 ESM unter Windows Server 2008 nicht unterstützt wird. Die Verwaltung von Exchange Server 2003-Servern muss entweder von Windows Server 2003- oder Windows XP-Arbeitsstationen durchgeführt werden. Alternativ dazu können Sie die Remotedesktopverbindung von einem beliebigen Betriebssystem aus verwenden.

F: In meiner Domäne führe ich mehrere Exchange Server 2003-Server aus. Werde ich meine Domänencontroller auf Windows Server 2008-Domänencontroller aktualisieren können?
A: Ja, das Ausführen von Exchange Server 2003 SP2 in der Domäne, in der die Windows Server 2008-Domänencontroller installiert sind, wird unterstützt. Beachten Sie, dass Exchange Server die Windows Server 2008-Read-Only-Domänencontroller (read-only domain controllers, RODC) oder die globalen Read-Only-Katalogserver (read-only global catalog servers, ROGC) nicht verwenden kann. Die manuelle Festlegung (Hartcodierung) von Exchange Server für die Verwendung des Windows Server 2008-RODC/ROGC kann zu unerwartetem Verhalten führen.

Nino Bilic ist Supportability Program Manager für Exchange und verbringt seine Freizeit damit, sich in die Feinheiten der Server-zu-Server-Kommunikation zu vertiefen, indem er vor der Nachtruhe noch eine Flut von Netmon-Ablaufverfolgungen liest.
Scott Landryist Support Escalation Engineer für Exchange Server und nimmt, wohin er auch geht, sein Handtuch, ein Exemplar des Handbuchs und sein bewährtes Windows Mobile-Telefon mit.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.
Communityinhalt   Was ist Community Content?
Neuen Inhalt hinzufügen RSS  Anmerkungen
Processing
Page view tracker