E-Mails senden von Druckern, Multifunktionsgeräten, Servern, Skripten aus Microsoft365/Office365

Wer mit der Migration zu Office365 bzw. Microsoft365 fertig ist und sich vorher nicht ausreichend Gedanken gemacht hat, wird jetzt folgendes feststellen: Die Kollegen können ihre eingescannten Dokumente nicht mehr erhalten. Ebenso kommen Log-E-Mails des Backup-Servers nicht mehr an. Natürlich ist durch den Wegfall des lokalen Exchange-Servers auch die Möglichkeit entfallen lokal über diesen E-Mails zu verschicken. Im Regelfall wurden zusätzliche Postfächer für die Geräte oder aber Freigaben für die entsprechenden IP-Adressen der Geräte eingerichtet. Dies geht nun nicht mehr. Die Alternativen und wie ich es umgesetzt habe zeige ich in diesem Artikel.
 

Möglichkeiten und damit verbundene Probleme

• Grundsätzlich könnte man natürlich einfach ein Konto aus Microsoft365 nutzen, sofern es sich auf den betroffenen Geräten einrichten lässt. Dies hat natürlich einen großen Nachteil: Es wird eine Lizenz benötigt, da das Gerät nun ein Microsoft365-Benutzer ist. Ob es dann lizenzrechtlich in Ordnung ist dieses Konto für 100 Geräte zu nutzen ist vermutlich auch wieder Auslegungssache.
• Alternativ könnte man natürlich auch einfach bei einem beliebigen Free-Mail-Anbieter, solange eine geschäftliche Nutzung erlaubt ist, oder bei einem günstigen Provider irgendeiner anderen Domain eine Mail-Adresse anlegen und dafür nutzen. In der Vergangenheit hatte ich zumindest als ich einen Free-Mail-Anbieter zum Testen genutzt. Dabei hatte ich aber, bei meinem absoluten „Lieblingsprodukt“ WSUS, ein Problem aufgrund der Authentifizierung. Ob dies mit einem Microsoft365-Mailkonto auch auftaucht habe ich aber bisher nicht getestet.
• Man kann Microsoft365 mittels eines Connectors auch als Relay nutzen. Hierzu wird ein Connector in Microsoft365 erstellt, der E-Mails von der öffentlichen festen IP-Adresse des Unternehmens annimmt. Ob es wirklich ein Problem ist oder nicht: Dadurch ist jedes Gerät im Unternehmen für Microsoft365 berechtigt dieses als richtiges Relay zu nutzen und unter beliebigen Mail-Adressen der betroffenen Domain(s) Mails an intern und auch extern zu verschicken! Wenn man das nicht möchte, muss man beispielsweise per Firewallregel dazwischen gehen und die Kommunikation an die SMTP-Ports unterbinden. Alternativ kann ein (nicht-selbstsigniertes) Zertifikat statt der IP-Adresse genutzt werden. Die Installation des Zertifikats werden aber mit Sicherheit irgendwelche alten Geräte nicht unterstützen.
• Man kann auch direkt E-Mails an den MX-Endpunkt senden, wie auch beim Einsatz des Connectors. Damit das ganze nicht im Spam-Ordner endet ist dann nur ein SPF-Eintrag nötig. Hier ist allerdings dann ebenfalls der Nachteil, dass theoretisch von jedem Gerät hinter der öffentlichen IP-Adresse unter einer beliebigen Mail-Adresse E-Mails verschickt werden können. Gegenüber dem Relay gibt es aber einen großen Vorteil: Dies funktioniert dann zumindest nur an interne Empfänger in der Domäne!

Bei allen bisher genannten Varianten gibt es meiner Meinung nach folgende Probleme: Alle Geräte die E-Mails schicken können sollen, müssen direkt nach draußen ins Internet kommunizieren dürfen. Zumindest die jeweils nötigen SMTP-Ports müssen erreichbar sein. Ohne Nutzung eines Extra-Mail-Kontos sind beliebige interne Mail-Konten als Absender zumindest an interne Empfänger nutzbar.

Wenn man mit der beschriebenen Tatsache leben kann, würde ich die zuletzt beschriebene Variante (MX-Endpunkt und SPF-Eintrag) empfehlen. Somit sind zumindest keine externen Empfänger zulässig.

Wenn man nur eine dynamische IP-Adresse hat, sollte man sich überlegen doch einen Microsoft365-Benutzer bzw. eine Lizenz zu „opfern“. Denn dynamische IP-Adressen stehen leider sehr oft auf einer Spam-Blackliste. Auch ein DynDNS-Eintrag dürfte daran nichts ändern, da die Quell-IP-Adresse dann noch geblockt ist. Man müsste sich anosntent wohl eine feste IP-Adresse organisieren. Beim Versuch aus Powershell eine Mail zu senden bekommt man dann bspw. folgende Fehlermeldung:

Dies ist mir direkt beim Testen über meinen heimischen PC passiert, obwohl die dynamische IP-Adresse im SPF-Eintrag hinzugefügt worden ist. Auch mit einem Connector in Office365 wird die E-Mail nicht angenommen.

Meine Lösung

Wie bereits in meinem alten Artikel habe ich mich dafür entschieden, aufgrund der ganzen (vielleicht übertriebenen?) genannten Bedenken und bekannten Probleme, einfach lokal einen SMTP-Server zwischen die lokalen Geräte und Microsoft365 zu setzen. Zuerst wollte ich dafür einen aus Testphasen noch vorhandenen Postfix-Server nutzen. Allerdings kann ich davon nur abraten, da es auch nach anfangs funktionierenden Testversuchen immer wieder zu Fehlern kam. Irgendwann akzeptierte Microsoft365 die E-Mails einfach nicht mehr. Warum konnte ich nicht klären und habe die Nutzung deshalb recht schnell wieder verworfen.

Letztlich habe ich auf einem Windows-Server, der unter einer anderen öffentlichen festen IP-Adresse als alle anderen Geräte nach draußen geht, das Feature „SMTP-Server“ installiert. Diese öffentliche IP habe ich in einem SPF-Eintrag zur Vermeidung der Kategorisierung als Spam hinzugefügt. Wenn man keine weitere öffentliche IP-Adresse hat bringt einem dieses Vorgehen in Bezug auf die Nutzung von Microsoft365 durch alle Geräte im Netzwerk aufgrund des SPF-Eintrags allerdings nichts. Dann kann man sich das ganze sparen oder muss per Firewall für einzelne Geräte die SMTP-Nutzung freigeben. Die Nutzung der anderen öffentlichen IP kann man z. B. durch eine NAT-Regel für den Windows-SMTP-Server erreichen.

In den Einstellungen der lokalen Geräte habe ich dann die IP-Adresse des lokalen SMTP-Servers verwendet. Die IP-Adresse der Geräte habe ich in den Einstellungen des SMTP-Servers freigegeben. Somit sollten nur die explizit freigegebenen Geräte in den Genuss kommen unter einer beliebigen Mail-Adresse Mails intern in Microsoft365 schicken zu können. Extern ist wie beschrieben dann komplett außen vor!