Azure SMTP

Wer Dienste in Azure betreibt, möchte auch von dort Mails versenden. Das ist aber nicht immer einfach, denn in Azure gibt es einiges zu Bedenken. Microsoft will z.B. verhindern, dass Azure-VMs als "Spamschleuder" missbraucht werden und damit die Reputation beschädigen. Wie geht mal also damit um?

Update: Mai 2022: Email in Azure Communication Services (Preview)
https://docs.microsoft.com/en-us/azure/communication-services/concepts/email/email-overview

Wer sendet Mail?

Da stellt sich natürlich erst einmal die Frage, welche Dienste und Prozesse überhaupt Mails versenden müssen. Ich sehe da folgende Szenarien:

  • Benachrichtigungen an den Betreiber
    Ein Service oder Server in Azure kann natürlich den verantwortlichen Betreiber per Mail über Probleme informieren. Das ist z.B. bei schnell entwickelten Skripten eine gerne genutzte Möglichkeit. Besser wäre natürlich immer auch eine Integration in eine Monitoring-Lösung wie z:B. SCOM oder PRTG. Dennoch ist hier der Fokus ab und an mal eine Mail an z.B. den eigenen Tenant zu senden.
  • Benachrichtigung an Kunden
    Wenn Dienste in der Cloud mit Kunden interagieren, dann ist der Versand von Mails an Kunden erforderlich, z.B.: um die Gültigkeit einer Mailadresse zu überprüfen (Opt-In) oder als Hilfsmittel eines Kennwort-Reset. Wenn ein Service entsprechend aktiv genutzt wird, können das auch mal viele Mails werden.
  • Gateway-Betrieb
    Wer nicht auf Exchange Online setzt, sondern seine eigene Gateway-Lösung nutzen will, könnte auch der Versuchung nachgeben, diese Lösung einfach in Azure zu hosten. In dem Fall empfängt das System Mails aus dem Internet aber auch von "intern" und versendet Mails in beide Richtungen. Hier kommt authentifizierter und anonymer Verkehr aus beiden Seiten und beide Richtungen zusammen.

Schauen wir uns also mal an, was Azure kann:

Azure und Port-Beschränkungen

Microsoft verkauft in Azure neben vielen anderen Diensten auch "VMs", d.h. virtuelle Maschinen mit unterschiedlichen Ausbaustufen bezüglich CPU, RAM, DISK. Sie können als Kunde einer AzureVM natürlich eine feste IP-Adresse kaufen, die dann auch beständig ist. Das ist für den Empfang von Mails natürlich erforderlich, da MX-Records auf DNS-Namen zwar möglich sind, aber durch das DNS-Caching nicht sichergestellt wäre, dass alle einliefernden Server nach einem Neustart einer Azure-VM auch sofort die neue Adresse nutzen. So sollte einem Betrieb in Azure auf den ersten Blick nichts entgegen stehen.

Auf der anderen Seite hat Microsoft natürlich auch die Aufgabe ihre IP-Adressen zu schützen. Wenn also jemand mit einer "Test-Subscription" oder geklauten Kreditkartennummern einen Tenant eröffnet, VMs in Sekunden bereitstellt um damit Massenmails zu verteilen, dann hat Microsoft da natürlich zurecht etwas dagegen. Zudem möglich Microsoft natürlich seine "Exchange Online Protection"-Plattform stärken und auch Exchange Online verkaufen. Sie können Exchange Server mittlerweile auch in Azure installieren, aber nur auf "Premium Storage". Das treibt die Kosten schon etwas in die Höhe.

Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.
Quelle: Exchange 2016 virtualization  https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160

Im gleichen Artikel steht aber noch eine viel wichtigere Aussage:

The only supported way to send emails to external domains from Azure compute resources is via an SMTP relay (otherwise known as a SMTP smart host). The Azure compute resource sends the email to the SMTP relay and then the SMTP relay provider delivers the email to the external domain. Microsoft Exchange Online Protection is one provider of an SMTP relay, but there are a number of third party providers as well
Quelle: Exchange 2016 virtualization  https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160

Eine Mail kann nicht direkt versendet werden. Das wird von Azure geblockt. Genauso wie z.B. ICMP-Antworten.

Insofern bleiben nur der Versand über einen "Provider".

Azure und SMTP Ausgehend

Ganz so absolut ist die Aussage von Microsoft aber nicht, denn es gibt andere Zitate:

Aus dem Artikel gehen drei Aussagen hervor:

  • Alle „Enterprise Agreement Subscriptions“ dürfen

„For Enterprise Agreement Azure users, there's no change in the technical ability to send email without using an authenticated relay. Both new and existing Enterprise Agreement users can try outbound email delivery from Azure VMs directly to external email providers without any restrictions from the Azure platform.“
Quelle: https://docs.microsoft.com/de-de/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

  • Alle Pay as you go“ Subscription vor dem 15. Nov 2017 dürfen

“If you signed up before November 15, 2017 for the Pay-As-You-Go or Microsoft Partner Network subscription offers, there will be no change in the technical ability to try outbound email delivery.”
Quelle: https://docs.microsoft.com/de-de/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

  • Alle Pay as you go“ Subscription NACH dem 15. Nov 2017 dürfen nicht mehr

For Pay-As-You-Go or Microsoft Partner Network subscriptions that were created after November 15, 2017, there will be technical restrictions that block email that’s sent directly from VMs within these subscriptions.
Quelle: https://docs.microsoft.com/de-de/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

Da die meisten Firmen nicht unter EA fallen, und sicher mehr Firmen erst nach dem Nov 2017 mit Azure begonnen haben, dürfte der letzte Punkt meistens zutreffen. Aber auch in dem Fall kann es eine Lösung geben. Sie können den Versand per SMTP nämlich auch freischalten lassen.

If you want the ability to send email from Azure VMs directly to external email providers (not using an authenticated SMTP relay), you can make a request to remove the restriction. Requests will be reviewed and approved at Microsoft’s discretion, and they'll be granted only after additional anti-fraud checks are made. To make a request, open a support case by using the following issue type: Subscription Management Problem type: Request to enable Port 25 email flow. Make sure that you add details about why your deployment has to send mail directly to mail providers instead of using an authenticated relay.
Quelle: https://docs.microsoft.com/de-de/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

Es "sollte" also möglich sein.

Wenn ich aber meine Kollegen aus dem NoSpamProxy-Team frage, dann winken diese doch sehr schnell ab. Ja, es sollte gehen aber es klappt meist nicht bzw. die Berechtigung geht wohl auch mal wieder verloren. Man könnte fast vermute, dass es von Microsoft nicht "gewollt" wird oder es einfach zu viel Arbeit ist, IP-Adressen direkt senden zu lassen und sich mit der Blocklist-Thematik auseinander zu setzen.

Versand über Azure Communication Services

Im Februar 2023 war die Funktion noch in "Preview". Microsoft möchtet aber wohl auch einen eigenen SMTP-Versanddienst über Azure etablieren, damit man niciht selbst einen Mailversand-Server aufbauen muss. Genutzt habe ich den Service aber noch nicht.

Send an email with Azure Communication Services
https://www.youtube.com/watch?v=t0in_d9Q2mU 

Versand über Office 365, SendGrid u.a.

Microsoft platziert natürlich seinen eigenen Exchange Online-Service als legitimen Provider zum Versand von Mails. Wer also schon einen entsprechenden User und Account hat, kann einfach Mails von Azure über den Smarthost "smtp.office365.com" versenden. Natürlich muss sich ihr Konto entsprechend authentifizieren, wie in dem Beispiel auf der folgenden Webseite schön gezeigt wird: 

SmtpClient client = new SmtpClient();
  client.UseDefaultCredentials = false;
  client.Credentials = new System.Net.NetworkCredential("O365 UID", "O365 PASS");
  client.Port = 587;
  client.Host = "smtp.office365.com";
  client.DeliveryMethod = SmtpDeliveryMethod.Network;
  client.EnableSsl = true;

Die Anmeldung per SMTP mit Benutzername/Kennwort funktioniert auch noch nach der Abschaltung von BasicAuth für normale Exchange Zugriffe. Siehe Exchange Online Authentifizierung

Ein so konfigurierter Mailversand funktioniert nicht nur in Richtung ihres eigenen Tenants sondern auch zu allen anderen Empfängern der Welt. Aber auch hier gibt es Limits.

Grenzwert Wert Link

Message Received per Hour

3600

https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#RecipientLimits
60 Mails pro Minute sind auch "nur" 1 Mal/Sek. Für ein Postfach sollte diese Grenze sicher kein Problem sein aber für automatisierte Postfächer kann es hier schon zu Grenzen kommen.

Empfänger pro Tag

10.000

https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#Receiving and sending limits

Nachrichten pro Zeit

30/Min

https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#Receiving and sending limits
Ein System kann also maximal eine Nachricht alle 2 Sekunden senden

Es gibt noch weitere Limits aber diese beiden Grenzen sind für normale Anwender kaum zu erreichen aber für automatische Prozesse durchaus ein begrenzender Faktor. Daher ist Exchange Online Protection auch nicht wirklich eine Lösung für "Massenmails" sondern eher für die Individual-Kommunikation zwischen Menschen und speziellen Diensten.

Die Lücke, die Microsoft hier in ihrem Angebot lässt, füllen natürlich andere Anbieter gerne aus. Eine Suche im Azure Marketplace nach E-Mail liefert alternativer Anbieter wie z.B. SendGrid und Mailjet:

Anscheinend haben aber auch die Azure-Leute bei Microsoft schon gemerkt, dass ihre eigene Plattform für Massenmails nicht optimal ist und beschreiben selbst, wie z.B. Sendgrid zu integrieren ist. Aber auch die API von Mailjet ist denkbar einfach.

Die SendGrid-Plattform kann direkt im Azure Marketplace quasi bestellt werden und die "Free-Version" ist mit 25.000 Mails/Monat durchaus für erste Gehversuche interessant.

Allerdings hat der Versand über einen Provider auch immer das Problem, dass ihre Solution die Mail erst mal schnell los wird aber sich dann auch um die Rückläufer selbst kümmern muss. Als Applikation fehlen ihnen einige Optionen, die bei einer direkten Verbindung zur Verfügung stehen, z.B.

  • STARTTS
    Wenn Sie selbst senden, können Sie je nach Ziel selbst z.B. STARTTLS erzwingen und das Zertifikat der Gegenseite prüfen. Das ersetzt zwar keine echte Verschlüsselung/Signierung mit S/MIME oder PGP aber ist in vielen Fällen schon einmal besser.
  • Abfangen von Fehlern
    Wenn die Gegenseite die Mail aus verschiedenen Gründen nicht annehmen will, dann bekommen Sie sofort einen SMTP-Fehler. Das ist insbesondere dann wichtig, wenn Sie SMTP aktiv nutzen, um die Gültigkeit von eingegebenen Namen direkt zu prüfen. Auch andere Fehler bekommt nun das Relay-System ihres Anbieters und generiert eine NDR-Meldung, die ihr Code asynchron wieder auswerten und zuordnen muss.
  • Source-IP auf der Gegenseite
    Sie können der Empfängerseite auch nicht dabei unterstützen, sie zu erkennen. Sie haben keine eigene IP-Adresse, wenn Sie über einen Provider senden. Der Empfänger kann sie also nicht anhand einer IP-Adresse "bevorzugen".
  • Client-Zertifikate
    Beim Einsatz von STARTTLS kann man auch mit Client-Zertifikaten arbeiten, d.h. Sie als Versenden können der Gegenseite auch "ihr Zertifikat" senden. Das wird von Exchange Online im Hybrid-Mode genutzt, um die Exchange Server der Organisation unabhängig von der IP-Adresse zu identifizieren und einen entsprechenden Vertrauenslevel zuzuweisen. Das geht beim Versand über einen 3rd-Party-Dienstleister natürlich nicht.

Aber zumindest können sie schon mal "senden".

Mail-Gateways in Azure

Aber wer sich den Azure Marketplace anschaut, findet dort auch Lösungen für Gateways, die als Alternative zu Exchange Online Protection platziert werden. Sie schützen alle mehr oder weniger gut gegen Spam und Viren und liefern ggfls. Zusatzfunktionen wie Verschlüsselung und Signierung von Mails. Eine Bewertung gebe ich nun besser nicht ab, da ich hier nicht neutral bin (Net at Work stellt das Produkt NoSpamProxy her)

Eingehende Mails kann so eine Azure-VM natürlich wie gewohnt bedienen. Sie vergeben einfach eine statische IP-Adresse und verweisen ihre MX-Record darauf. Nur beim Versand wird es wieder aufgrund der SMTP-Limits etwas aufwändiger. Hier gibt es dann verschiedene Optionen.

  • Versand über Exchange Online
    Sie nutzen den Versand über Exchange Online als "Authenticated Sender".  Hier kommen natürlich auch die Throttling-Grenzen zum Einsatz und genutzt werden kann nur die Mailadresse, die dem Benutzer auch zugeordnet ist.
  • Versand über Exchange Online mit Inbound-Connector
    Wenn ihre AzureVM eine fest IP-Adresse hat, können Sie natürlich in ihrem Exchange Online Tenant einen "Inbound Connector" anlegen, über den ihre Applikation dann Mails an Office 365 senden und über Office 365 als Relay auch in das Internet senden kann. Hier kommen natürlich auch die Throttling-Grenzen zum Einsatz.
  • Versand über SendGrid u.a.
    Wenn Sie über einen Dienstleister gehen, dann entfallen die Versand-Limits, die Office 365 anwendet. Allerdings helfen ihnen die oben schon aufgeführten Funktionen.
  • Versand über eigenen SOCKS/TCP-Proxy
    Sie können natürlich die Leistung von Azure nutzen, um ihre Appliance zu starten aber sich eines Hilfssystems zum Versand zu bedienen. Sie könnten bei einem anderen Hoster einfach einen TCP-Proxy laufen lassen, der Verbindungen von ihrem System in Azure nach erfolgter Authentifizierung annimmt und an die gewünschte Zieladresse weiter leitet. Quasi so etwas wie ein "NAT" auf Applikationsebene. Dazu ist es natürlich erforderlich, dass ihr Gateway einen solchen Proxy unterstützt, eine Authentifizierung möglich ist und sie bei einem anderen Provider einen entsprechenden Proxy betreiben.

Das gesamte Setup ist für eingehende Verbindungen natürlich nicht relevant, da hier Azure keine Beschränkungen auferlegt. Wer also einen eigene Anti-Spam-, Antiviren- und vor allem Verschlüsselungslösung betreiben will, kann dies in Azure gerne tun. Nur für den Weg nach Extern müssen die Einschränkungen von AzureVMs entsprechend bedacht werden.

Weitere Links