IMAP4 mit Office 365

Alle Postfächer in Office 365 sind nicht nur per Outlook , OWA, ActiveSync und EWS erreichbar. Exchange Online unterstützt natürlich auch weiterhin IMAP4 und POP3-Clients, die auch per SMTP einliefern. Das kann sinnvoll sein, da diverse IMAP4-Client auch als PortableApp auf einem USB-Stick laufen oder auch Linux als Client ernst genommen werden. Hier beschreibe ich die wesentlichen Einstellungen.

IMAP und OAUTH

ACHTUNG: Ab Oktober 2021 muss die Anmeldung per POP3/IMAP per OAUTH erfolgen. Siehe auch Exchange Online Authentifizierung

Wer eine Applikation nutzt, die nur per IMAP mit einem Exchange Server kommunizieren kann und auch in absehbarer Zeit nicht mit OAUTH zurecht kommt, der hat mit Office 365 eine Herausforderung. Theoretisch ist es denkbar, einen IMAP4-Proxy aufzubauen, der zur Applikation wie ein IMAP-Server aussieht und gegen Office 365 sich dann per OAUTH anmeldet. Theoretisch könnte so etwas sogar per PowerShell entwickelt werden. Es gibt natürlich schon viele IMAP4-Proxy-Server, die als Loadbalancer oder Application Firewall arbeiten aber ich habe noch keinen gesehen, der die Authentifizierung umstellen kann.

Ein interessanter Kandidat könnte DavMail sein.

DavMail stellt den Clients die "standardisierten RFC-Protokolle" bereit und greift seinerseits auf EWS zu. DavMail unterstützt OAUTH über "Application Passwords" und sie müssen DavMail natürlich als Application registrieren

So könnten Sie vielleicht ein Postfach in der Cloud mit einer lokalen Instanz von DavMail für einen internen Service erreichbar machen.

Technisch sollte aber auch ein einfacher IMAP4-Proxy schnell umsetzen sein, der einfach nur die Authentifizierung entsprechend umsetzt. Mail im Internet - IMAP4-Telnet

IMAP4/POP3 mit SSL, SMTP mit StartTLS

Dass der Zugang auch per IMAP4 und POP3 möglich ist, ist so erst mal kein Geheimnis. Microsoft veröffentlicht die Daten:

Folgende Adressen sind in Office 365 zu nutzen:

Protokoll

Server FQDN TCP Port Verschlüsselung

POP3

outlook.office365.com

995

TLS

IMAP4

outlook.office365.com

993

TLS

SMTP

smtp.office365.com

587

STARTTLS

Microsoft nutzt konsequent TLS bzw. STARTTLS. So ist sichergestellt, dass jegliche Übertragung von Daten aber auch der Anmeldung immer verschlüsselt ist. Voraussetzung ist natürlich, dass der Anwender auch die Rechte zur Nutzung von POP3/IMAP4 hat. Die sind per Default allerdings eingeschaltet und können abgeschaltet werden.

Thunderbird

Ein gängiger IMAP4 Client auf Windows, Portable App u.a. ist natürlich Mozilla Thunderbird. Hier können Sie einfach über den Assistenten ihre Mailadresse eingeben. Mozilla pflegt selbst eine Datenbank der IMAP4/POP3-Provider und wenn sie hier ihre "onmicrosoft.com"-Adresse angeben, dann findet Thunderbird ganz alleine die richtigen Einstellungen.

Interessanterweise weichen diese Einstellungen von den Microsoft Defaults ab. Da sind in der Mozilla Datenbank wohl andere Werte hinterlegt. Anders sieht es natürlich aus, wenn Sie eine eigene Domain verwenden. Bei einer Adresse aus "uclabor.de" kommt keine funktionierende Konfiguration zustande.

Thunderbird versucht ähnlich wie Exchange Autodiscover einen "autoconfig"-Eintrag auszuwerten.

GET http://autoconfig.uclabor.de/mail/config-v1.1.xml?emailaddress=admin%40uclabor.de HTTP/1.1
Host: autoconfig.uclabor.de User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Lightning/5.4.6
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

Hier kommt natürlich bei Office 365 nichts zurück. Sie könnten aber für ihre Domäne natürlich diesen DNS-Eintrag anlegen und auf eine Webseite verweisen lassen, die dann die richtigen Daten liefert. Schade eigentlich, dass Office 365 diesen Service mit mit anbietet und autoconfig als DNS-Eintrag vorschlägt. Anscheinend gibt es doch nicht so viele IMAP4-Clients mit Anwendern, die eine automatische Konfiguration benötigen. Thunderbird versucht aber weiterhin noch ein paar Namen zu erraten wie imap.<domain> und smtp.<domain>. Wer es seinen Anwendern leichter machen will, kann im DNS entsprechende CNAME-Einträge hinterlegen:

imap.msxfaq.com  CNAME  outlook.office365.com
pop.msxfaq.com   CNAME  outlook.office365.com
smtp.msxfaq.com  CNAME  smtp.outlook365.com

So sollte dann auch zumindest Thunderbird und Programme mit einer ähnlichen Logik dem IMAP und Client-SMTP-Server finden. Wenn dann, wie bei Exchange Online, die Mailadresse zugleich der Anmeldename (UPN) ist, dann ist der Client schon fertig konfiguriert.

Authentifizierung

Bei eine Anmeldung per IMAP4 oder POP3 ist es natürlich nicht vorgesehen, dass ein Fenster geöffnet wird, in dem ein Client einen zweiten Faktor (MFA) angeben kann o.ä. Darauf müssen Sie natürlich achten, wenn Sie mit MFA oder ADFS arbeiten, dass der Client OAUTH2 unterstützt oder Sie eine "Basic Authentication" erlauben. Wenn Sie Thunderbird anschauen, dann gibt es schon einige Verfahren zur Anmeldung:

Achten Sie darauf, dass SMTP mit "STARTTLS" die Verschlüsselung einleitet und IMAP4 direkt mit SSL/TLS startet und daher theoretisch auch ein Client-Zertifikat mitliefern kann. Das ginge mit STARTTLS auch aber beides ist mit Office 365 nicht möglich. In Zukunft wird aber OAUTH wichtig werden.

Dennoch stellt sich natürlich die Frage, welche Verfahren nun Office 365 "versteht"

  • Tests mit POP3
    Die erspare ich mir, die Anmeldung ist gleich aber Anwendungsfälle sind aus meiner Sicht selten
  • Nur mit Verschlüsselung
    Ohne Verschlüsselung würde ich keinen Zugriff machen. Office 365 bietet beim anonymen Zugriff gar nicht erst eine Authentifizierung (LOGINDISABLED) an

Anders sieht es mit IMAP per SSL/TLS aus. was per OpenSSL recht einfach geht:

Aktuell (Stand Nov 2020) wird von Office 365 nur "PLAIN TEXT" und eben XOAUTH2 angeboten. Andere auch von Thunderbird unterstützte Verfahren wie Kerberos, GSSAPI, NTLM etc. kommen nicht zum Einsatz.

Es fehlt nun noch der Test für SMTP. Ich verbindet mich auf den Port 587 per Telnet und auch hier ist werden keine Anmeldeoptionen angeboten.

Allerdings offeriert mit die Cloud die Funktion "STARTTS. Erst wenn sich mit STARTTLS die Verbindung dann verschlüssle, sehe ich mehr:

Aber auch hier wird nur "LOGIN" und "XOAUTH2" angeboten.

Eigentlich könnte ein Mailprogamm selbständig die möglichen Verfahren ermitteln und dem Anwender nur die Wahl zwischen "Unsicher" und "Sicher" lassen.

Achtung:
Microsoft wird bald die "BasicAuth" in Exchange Online abschalten und OAUTH anfordern. Nur so kann der Service auch MFA, ConditionalAccess, Application Compliance etc. umsetzen
Siehe auch Exchange Online Authentifizierung

  • MFA mit App-Kennwort
    Wenn Sie Multi Faktor Authentifizierung (MFA) für den Client vorschreiben, dann habe ich bislang immer mit einem App Password gearbeitet.
  • ADFS Anmeldung
    Eine Anmeldung per ADFS ist möglich. Da aber die meisten IMAP-Client natürlich ADFS nicht nativ unterstützen, sendet ihr Client die Anmeldedaten an den IMAP-Server, der dann "on behalf" des Anwenders eine ADFS-Anmeldung durchführt. Das ist bei älteren ActiveSync Client aber genau so
  • Pass-Through Authentifizierung (PTA)
    Auch hier sendet der Client das Kennwort zum Backend, welcher dann über den PTA-Agent die Verifikation durchführt. In der Regel unterstützen die Clients kein Kerberos
  • Cloud Kennwort
    Die Anmeldung mit einem AzureAD Konto samt Kennwort geht natürlich auch

Bis auf den Einsatz von MFA sind also alle anderen Wege direkt möglich.

IMAP4/POP3 steuern

Bei Exchange OnPremises haben Sie einfach die POP3/IMAP4-Dienste beendet, damit niemand diese Protokolle nutzen konnte. Wenn aber nur ein Benutzer mit OP3/IMAP4 arbeiten musste, liefen die Dienste und sie mussten sich einen anderen Weg einfallen lassen. Wie OnPremises können Sie auch in der Cloud den Zugriffe per IMAP4/POP3 direkt deaktivieren.

Set-CasMailbox `
   -identity <user> `
   -imapenabled:$false `
   -popenabled:$false

In Exchange Online können Sie sogar "Templates" anlegen, bei der diese Einstellungen bei der Neuanlage eines Benutzers übernommen werden. Diese Optionen sind aber aus Kompatibilitätsgründen noch da, denn in Verbindung mit OAUTH gibt es in Exchange Online eine Steuerung über Richtlinien (Authentication Policies)

Sie legen daher am besten in ihrem Tenant entsprechende Richtlinien an, mit denen Sie Zugriffe sperren oder erlauben. Ein einfache "New-AuthenticationPolicy" reicht schon

PS C:\> New-AuthenticationPolicy -name NoBasicAuth

RunspaceId                         : 2440c6a7-74b3-4aff-938b-60e3b2c5e9c1
AllowBasicAuthActiveSync           : False
AllowBasicAuthAutodiscover         : False
AllowBasicAuthImap                 : False
AllowBasicAuthMapi                 : False
AllowBasicAuthOfflineAddressBook   : False
AllowBasicAuthOutlookService       : False
AllowBasicAuthPop                  : False
AllowBasicAuthReportingWebServices : False
AllowBasicAuthRest                 : False
AllowBasicAuthRpc                  : False
AllowBasicAuthSmtp                 : False
AllowBasicAuthWebServices          : False
AllowBasicAuthPowershell           : False
AdminDisplayName                   :
ExchangeVersion                    : 0.20 (15.0.0.0)
Name                               : NoBAsicAuth
Identity                           : NoBAsicAuth
ObjectCategory                     : NAMPR20A001.PROD.OUTLOOK.COM/Configuration/Schema/ms-Exch-Auth-Policy
ObjectClass                        : {top, msExchAuthPolicy}
ExchangeObjectId                   : f45bfd5a-a118-4b8f-8566-1234567890ab
Id                                 : NoBAsicAuth
Guid                               : f45bfd5a-a118-4b8f-8566-1234567890ab
OriginatingServer                  : BYAPR20A01DC005.NAMPR20A001.PROD.OUTLOOK.COM
IsValid                            : True
ObjectState                        : Unchanged

Ohne weitere Konfiguration oder Angabe beim Anlegen sind alle BasicAuth-Zugriffe deaktiviert. Sie sollten die Richtlinie nach ihren Anforderungen anpassen. Die so angelegten Richtlinien können Sie individuell den Benutzern oder auch als Standard auf die Organisation zuweisen, die dann der Default für alle Benutzer wird, die keine individuelle Richtlinie haben.

Da IMAP4/POP3 eher einfache Protokolle sind und Exchange Online Anwender besser mit Outlook, Browser oder Mobilclient arbeiten, würde ich ein globale Default-Richtlinie anlegen, die alles abschaltet und eine eigene Richtlinie für IMAP4 mit "AllowBasicAuthImap:$true " anlegen

Die organisationsweite Standardrichtlinie können Sie wie folgt ermitteln

PS C:\> (Get-OrganizationConfig) | fl DefaultAuthenticationPolicy
DefaultAuthenticationPolicy :

Normalerweise ist keine Richtlinie hinterlegt, so dass die Standardwerte von Microsoft zum tragen kommen. Diese können sich durchaus mal ändern.

Die Anweisung pro Benutzer erfolgt dann mit Set-User:

Set-User `
   -Identity <usernam> `
   -AuthenticationPolicy "BlockBasicAuth"

SMTP-Versand freischalten

Client, die ihre Mails per IMAP4/POP3 abholen, senden diese meist per SMTP. Auch hier sollte der Client immer TLS nutzen, sei es per SMTPS oder STARTTLS. Allerdings ist es nicht ratsam, dass alle Anwender SMTP nutzen können. Die meisten Anwender arbeiten ja mit Outlook, OWA, ActiveSync und haben daher gar nicht den Bedarf per SMTP Mails einzuliefern.

Neuere Tenants dürften per Default schon den SMTP-Versand durch Clients deaktiviert haben.

Das können Sie per Exchange Online PowerShell herausfinden

# Anzeigen der aktuellen Einstellung
(Get-TransportConfig).SmtpClientAuthenticationDisabled

# Globales Deaktivieren der SMTPClientAnmeldung
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Mein Tipp: Schalten Sie Client-SMTP auf der Exchange Online Organisation ab und aktivieren Sie es selektiv für die Konten, die IMAP4/POP3 benutzen müssen.

# Zulassen für ausgewählte Postfächer
Set-CASMailbox `
   -Identity user1@uclabor.de `
   -SmtpClientAuthenticationDisabled $false

Weitere Links