Exchange 2007/2010 Internet Clients

SP 2007 SP1
Achtung, Servicepack setzt die Einstellungen wieder auf die Default-Werte zurück.

E2K7:Receiveconnector
Die richtige Konfiguration erlaubt den Clients den Versand an Exchange

Hinweise zur IMAP4 Performance unter Exchange 2010
http://blogs.technet.com/b/exchange/archive/2010/05/06/454836.aspx

Outlook Web Access 2007 ist sehr viel leistungsfähiger geworden und auch von Betriebssystemen ohne Internet Explorer nutzbar. Aber Evolution wird erst später wohl mit Exchange 2007 funktionieren und viele Anwender nutzen "nur" Mail und das hoch effizient. Da ist eine native Applikation immer noch besser als ein Browser.

Zudem viele Anwendungen mit IMAP4 auch einen Abgleich der Mailbox mit dem lokalen System erlauben und damit in gewissem Maße auch eine Offline-Funktion realisiert werden kann. Also stellt sich die Frage, wie solche Clients weiterhin an Exchange 2007 betrieben werden können:

Exchange 2007 ist sicher by Default

Unverschlüsselte Kennworte sind bei POP3 und IMAP4 leider die Regel. Zwar kann man schon immer auch diese Protokolle per SSL verschlüsseln und alternative Anmeldeverfahren gibt es auch, aber die Mehrzahl der POP3/IMAP4-Verbindungen werden immer noch ungesichert hergestellt.

Da allerdings das Anmeldedaten für die Mailbox identisch mit der Windows Anmeldung sind, sollten Sie niemals diese schwache Absicherung zulassen. Es gibt automatisierte Programme (z.B. Cain&Abel auf www.oxid.it), welche wirklich jeder Anwender auf einem Windows PC installieren,  starten und damit gezielt diese Kennworte mitschneiden kann. Übrigens kann dieses Programm auch FTP-Anmeldungen, Webanmeldungen, SNMP etc. analysieren, sofern diese nicht per SSL verschlüsselt sind.

Exchange 2007 trägt diesem Problem durch zwei Einstellungen Rechnung:

  • Dienste gestoppt
  • Sichere Anmeldung erforderlich

Um also über POP3 und IMAP4 auf ihre Exchange Mailbox zugreifen zu können muss der Exchange Administrator erst die entsprechenden Dienste starten und auf automatisch stellen:

Dienste Startart ändern

Zudem muss ihr Mailprogramm eine "sichere" Anmeldung unterstützten.  In Outlook Express ist dies in den Konteneinstellungen zu finden:

OE Secure Passwort

Die Einstellungen des IMAP4 und POP3-Diensts stehen per Default auf "SecureLogin". Dies bedeutet, dass Sie nicht einfach mit einem "TELNET", wie auf POP3 per Telnet gezeigt, zugreifen können, sondern eine "sichere Anmeldung" verwenden müssen, z.B. NTLM, GSSAPI, CRAM-MD5 und andere.

POP3 und IMAP4 per SSL

Wenn die verwendeten Clients nun leider keine "sichere Anmeldung" unterstützen, dann sollten Sie SSL aktivieren und erzwingen. Die Nutzung von SSL hat nebenbei den weiteren Vorteil, dass die Nachrichten selbst auch verschlüsselt übertragen werden. Die zusätzlich erforderliche CPU-Leistung sollte heute kein Engpass mehr darstellen. Große Umgebungen können natürlich mehrere ClientAccess-Server installieren.

Die Konfiguration der Anmeldung muss über die Exchange Management Console erfolgen. Folgende Zeilen erlauben die "unsichere" Anmeldung mit einem Klartextkennwort

Set-popSettings -LoginType PlainTextLogin
Set-ImapSettings -LoginType PlainTextLogin

Damit Sie auch nie vergessen, dass Sie eine unsichere Anmeldung aktiviert haben, weist Sie Exchange im Eventlog mit einer Warnung darauf hin

Unsichere IMAP4/POP3 Anmeldung aktiv

Um die sichere Anmeldung wieder zu aktivieren,  sind folgende Zeilen auszuführen.

Set-popSettings -LoginType SecureLogin
Set-ImapSettings -LoginType SecureLogin

Sie können diese Befehle um Parameter erweitern um z.B.: die Ausführung auf entfernte Server auszuführen oder über eine Schleife gleich alle Server anders zu konfigurieren.

Die SSL-Bindungen müssen Sie aber ebenfalls per PowerShell eintragen. Ich habe  mir dazu über den IIS ein Zertifikat für den Server angefordert.  So ist es automatisch im richtigen Zertifikatsspeicher gelandet und dann über die PowerShell verbunden.

Set-PopSettings `
   -X509CertificateName pop3.msxfaq.local

Nun kann ich also auch mit Client, die keine "Sichere Kennwortanmeldung" unterstützen, mit  einer Klartextanmeldung über SSL einen sicheren Zugang erreichen. 

Als Anmeldenamen ist der UPN angeraten. Andere Varianten wie Domäne/Username noch die Mailadresse oder andere Varianten funktionieren vielleicht nicht immer . Es ist ein gutes Design, wenn der UPN zugleich auch die primäre Mailadresse des Anwenders darstellt.

Bitte lesen Sie hierzu auch die Seite POP3 und IMAP4 Clients, welche genauer auf die verschiedenen Anmeldenamen eingeht.

Quittungen und POP3

Eine etwas unschöne Eigenschaft hat Exchange 2007 zumindest auch mit SP1 noch im Bezug auf Quittungen und POP3. Ein Kommunikationspartner kann eine Mail an ihr Postfach senden und dabei sowohl eine "Zugestellt"-Quittung als auch eine "Gelesen"-Quittung anfordern. Ihr Mailserver wird beim Zustellen der Nachricht in ihr Postfach eine "Zugestellt" Quittung erzeugen und dem Absender zusenden, vorausgesetzt, dass der Administrator den Versand erlaubt hat.

Bislang war es aber immer so, dass Sie dann die Mail erst abholen und lesen mussten, wobei viele Programme sie dann gefragt haben, ob Sie dem Absender eine "Gelesen"-Quittungen senden wollen. Das ist mit Exchange 2007 leider etwas anders. Folgendes passiert

  •  Zugestellt Quittung
    • Wird durch den Server generiert
    • nicht vom Benutzer verhinderbar
    • Durch den Admin pro Domain steuerbar (remote Domain)
  • „Read“ beim POP3 Abruf
    • Durch den Server generiert
    • nicht vom Benutzer verhinderbar
    • Eventuell per Transportrule zu stoppen
      Im Header ist ein "Received: from „backendserver“ ... by: mapi"
      Im Header ist KEIN "X-Mailer":
  • "READ" durch Client
    • Wird durch den Client generiert
    • je nach Programm durch Benutzer blockierbar

Eine Lösung gibt es aktuell (SP1) noch nicht,. als Fix wäre ein Transportagent denkbar, welcher diese mittlere Quittung einfach abfängt und löscht. Ich hoffe aber dass dieses Verhalten zukünftig doch korrigiert wird.

IMAP4/POP3 und öffentliche Ordner

Während es per PO3 noch nie möglich war, mehr als nur den "Posteingang" eines Servers zu lesen, kann per IMAP4 auch die Ordnerstruktur eines Postfachs genutzt werden. Je nach Version konnte per IMAP4 sogar ein Zugriff auf öffentliche Ordner erfolgen. Die ist mit Exchange 2007 aktuell nicht mehr möglich, auch wenn wenn die Dokumentation etwas anderes sagt.

In the RTM version of Exchange 2007, the following client applications can access public folders:
Microsoft Office Outlook 2007
Microsoft Office Outlook 2003
Client applications that are compatible with Internet Message Access Protocol 4rev1 (IMAP4), such as Outlook Express
In Exchange 2007 SP1, the same client applications are used to access public folders, with the addition of Microsoft Office Outlook Web Access

Ich konnte das aber zumindest nicht über IMAP4 bestätigen.

SMTP-Versand und Relay

Das Abholen von Mails ist aber bei weitem nicht alles. Natürlich wollen meine Anwender auch Mails senden. Normale Clients senden dazu alle ihre Mails an den zentralen Mailserver, welcher diese Nachrichten dann entweder intern verteilt  oder an das Internet weiterleitet. Damit dieser Server kein offenes Relay ist, müssen sich die Anwender an diesem SMTP-Server natürlich authentifizieren.

Interessanterweise hat Exchange 2007 schon von Hause aus eine entsprechende Konfiguration eingebaut. Es gibt dazu einen "Receive Connector" beim jeweiligen Server. Diese Konfiguration ist nicht "global", sondern pro Server einzutragen.

Exchange 2007 Receive Connector

Dazu gehören natürlich auch einige Einstellungen. Interessant sind hier die Standardwerte für das Netzwerk. Es dürfen alle Systeme sich mit dem Exchange Server verbinden, aber sie müssen den Port 587 nutzen. Dies ist nicht der sonst bekannte Port 25/TCP, sondern schon länger sollten Endanwender diesen Port nutzen. So kann ein Provider z.B.: den Zugriff auf den "anonymen Port" 25 netzwerkseitig beschränken und Datenverkehr lenken.

Receive Connector Einstellungen Netzwerk

Natürlich können Sie hier auch noch einen Zugang über Port 25 eintragen, aber ich rate ihnen dazu, die Chance der Umstellung zu nutzen und authentifizierte Zugänge nur über diesen Port zuzulassen.

Entsprechende sollten Sie unter "Authentication" natürlich erzwingen, dass die Anwender sich anmelden müssen.  Auch hier sollten Sie SSL erfordern, damit die Zugangsdaten nicht einfach abgehört werden können.

receive Connector Einstellungen Anmeldung

Über vordefinierte Gruppen können Sie steuern, welche Benutzer diesen Zugang verwenden dürfen. Leider können Sie nicht nicht noch weitere eigene Gruppen addieren. Achten Sie darauf, dass die anonymen Benutzer nicht zugelassen sind.

Receive Connector Einstellungen Gruppen

Damit sind eigentlich alle Voraussetzungen für einen sicheren Betrieb ihres Exchange Servers als POP3/IMAP4 Server und als SMTP-Versandserver gegeben. Sie müssen den Anwendern nun nur noch folgende Daten mitteilen:

Postfachserver IMAP4 per SSL

Ihr Servername:993

Postfachserver POP3 per SSL

Ihr Servername:995

Postausgangsserver

Ihr Servername:587

Anmeldung

Username@domäne.tld

Kennwort

Ihr persönliches Kennwort

Aus Sicherheitsaspekten sollten Sie auf jeden Fall SSL einsetzen. Es ist überhaupt nicht schwer ein eigenes Zertifikat mit einer eigenen CA zu erstellen. Nicht alle Clients unterstützen die "sichere Kennwortauthentifizierung". Ein Zugriff ohne SSL mit Klartextkennworten sollten Sie unter allen umständen vermeiden.

Anonymes Relay für ausgewählte IP-Adressen

Es kann die Situation eintreten, dass ihre Clients von intern ohne explizite Anmeldung über ihren Exchange Server eine Mail in das Internet senden müssen. Bei Exchange 2000/2003 konnten Sie dazu auf dem virtuellen SMTP-Server die IP-Adressen diese Systeme manuell eintragen. Das geht bei Exchange 2007 so nicht mehr. Statt dessen müssen Sie hier nun einen alternativen Weg gehen:

  • Zweiter Receive Connector
    Legen Sie einen zweiten Empfangsconnector an, der "nur" anonym erreichbar ist und nur von den Systeme (IP-Adressen) erreicht werden darf, welche anonym die Relayfunktion benötigen. Sie können problemlos mehrere Receive-Connectoren auf einem Server auf der gleichen IP-Adresse konfigurieren. Es kommen die Einstellungen zum tragen, die am "engsten" sind.
  • "Jede Zieladresse" zulassen
    Normalerweise können nun diese System an Exchange was senden, aber Sie können Exchange noch nicht als Relay verwenden. Sie sollten nun aber keine SMTP-Domain "*" einrichten, welche extern alles zulässt. Damit sind sie ein offenes Relay. Statt dessen müssen Sie auf dem Receive-Connector jede Zieladresse annehmen. Dies geht nur über eine Stellung mittels PowerShell.
' Englische Exchange Server
Get-ReceiveConnector -identity "connectorname" `
| Add-ADPermission `
   -User "NT AUTHORITY\ANONYMOUS LOGON" `
   -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"
' Deutsche Exchange Server
Get-ReceiveConnector `
   -identity "connectorname" `
| Add-ADPermission `
   -User "NT-AUTORITäT\ANONYMOUS-Anmeldung" `
   -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Erst jetzt können die Absender "jede" Zieladresse erreichen und nicht nur die internen Empfänger ihrer Exchange Organisation. Es gibt angeblich noch eine alternative Möglichkeit, anonym ein Relay zu erlauben, indem man nämlich die Option "Extern gesichert" auswählt.

remoteSecured 

Dann verlässt sich Exchange darauf, dass über IPSec und VPNs sichergestellt wird, dass sich nur "bekannte" Systeme mit dem Connector verbinden. Damit bekommt dann jeder andere Client auch die Rechte, Firewalls sichergestellt ist, dass sich nur die gewünschten Systeme verbinden, die dann aber quasi "alles" machen dürfen inklusive des Missbrauchs als Relay. Allerdings kann man diese Option nur setzen, wenn man alle anderen Authentifizierungsverfahren deaktiviert, was dann aber wieder die Verbindung zwischen Hub/Transport-Servern und Remote Connectoren stört. Setzen Sie dies also nur mit einem eigenen Receive Connector einer Umgebung mit nur einem Server ein.

Benutzermanagement

Per Default können alle Exchange Benutzer per POP3 oder IMAP4 auf ihre Mailbox zugreifen. Allerdings können die Anwender das erst einmal ja nicht, da die Dienste gestoppt sind. Wenn Sie nun die Dienste aktiviert haben, dann können Sie dennoch pro Benutzer steuern, ob diese per POP3 oder IMAP4 auf ihre Mailbox zugreifen dürfen.

Wenn es z.B.: Firmenstandard ist, dass alle Personen Outlook verwenden sollen und es nur wenige Ausnahmen gibt, dann sollten Sie bei allen Benutzern den POP3/IMAP4-Zugriff deaktivieren. Allerdings fällt ihnen das über die grafische Oberfläche der Exchange 2007 Managementkonsole schwer, da es keine passenden EinstellMöglichkeiten dazu gibt.

Die Konfiguration liegt zwar wie bei Exchange 2000/2003 im Active Directory, aber in der Exchange Management Console gibt es keine Möglichkeit, diese Einstellungen zu ändern. Frühere Konfigurationen von Exchange 2003 werden übernommen. Auch meine Einstellungen per Grp2ExInet greifen weiter, da es die gleichen Einstellungen sind.

Eine Liste der Benutzer mit ihren aktuellen Einstellungen liefert ihnen der Befehl "GET-CASMAilbox", den Sie auch wieder mit Filterkriterien einschränken können.

Get-CASMailbox

Name ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled
---- ----------------- ---------- ---------- ----------- -----------
Administr...    True       True        True     True         True
Carius, F...    True       True        True     True         True
User1           True       True        True     True         True
User2           True       True        True     True         True
User3           True       True        True     True         True

Über den Befehl "Set-CASMailbox" können Sie dann die erlaubten Funktionen per Skript verändern.

POP3 over OWA

Technisch kann man per OWA jede Mail lesen und schreiben, Ordner durchsuchen und nahezu alle Aktionen durchführen. Man kann allerdings nicht offline arbeiten. Ein findiger Entwickler hat sich daher einen Proxy gebaut, der zum Exchange per OWA/HTTP spricht und auf der anderen Seite per POP3 die Mails einem beliebigen Client bereit stellt. Das kann sogar soweit gehen, dass eine Firme eigentlich nur das "sichere" OWA über HTTP im Internet bereitstellt und POP3 entweder nicht veröffentlicht oder gar deaktiviert. Durch solch einen Trick ist es einem Benutzer trotzdem möglich, per POP3 gegen Exchange zu arbeiten.

http://www.pop2owa.com/en/index.php?page=Why_POP2OWA.html#
If you have behind a firewall maybe OWA it's the only way to read your mail, because the port used to connect with your Exchange server are closed. OWA it'sa good product but, other Users prefer to read the mail off-line, directly from a mail client. Microsoft offer RPC over HTTP but it only work in Outlook 2003 with Exchange 2003 Server. POP2OWA its the better way if you don't like OWA and can't use RPC over HTTP

Allerdings sind damit dann wieder alle Probleme von POP3 vorhanden, besonders das "herunterladen und Löschen" ist ein Risiko. Nur diesmal hat der Anwender das Problem, dass der Zugriff auf dem IIS protokolliert wird und hier sowohl die Löschbefehle selbst als auch das "ungewöhnliche Zugriffsverhalten"  (Lesen aller Mails in kurzer Zeit) bald auffallen würde wird.

Weitere Links