msExchRequireAuthToSendTo

Diesem Feld im lokalen Active Directory habe ich eine eigene Seite gewidmet, da es in Exchange-Umgebungen für die Zustellung Mails an Postfächer relevant ist. Natürlich gab es auch für diese Seite einen Anlass: Eine Einladung an eine interne Gruppe wurde von einem Teilnehmer in seinen "Familienkalender" in der Apple-Welt übertragen, so dass die Angehörigen von diesem Termin wussten. Da bei dieser Kopie auch die Teilnehmer kopiert wurden, ist der Familien wohl davon ausgegangen, dass ein neuer Termin an alle Teilnehmer gesendet werden soll. Und letztlich ist so herausgekommen, dass der Verteiler schon länger auch extern erreichbar war. Das ist einfach nicht aufgefallen.

Gruppen

Wenn Sie eine Verteilergruppe in Exchange neu anlegen, dann ist die Standard-Konfiguration dieser Gruppe hinsichtlich der Zustellungsverwaltung wie folgt:

Auch per PowerShell sehen Sie diese Information:

Get-DistributionGroup systemingenieure@uclabor.de | ft name,primarysmtpaddress,RequireSenderAuthenticationEnabled
 
Name                      PrimarySmtpAddress                     RequireSenderAuthenticationEnabled
----                      ------------------                     ----------------------------------
Systemingenieure          systemingenieure@uclabor.de                                         True

Soweit gibt es hier erst mal nichts besonderes. Ich habe aber den Wert auch mal zwischen "True" und "False" umgeschaltet und geschaut, welche LDAP-Fehler sich ändern. Auch hier war es Genau ein Feld:

msExchRequireAuthToSendTo: TRUE

Diese Feld ist also per Default auf "TRUE" und das sollte auch so sein. Sie können es manuell auf FALSE setzen und schalten damit den Empfang für anonyme Absender frei. Exchange schützt also per Default alle Mailverteiler, dass diese von anonymen Absendern erreicht werden. Allerdings ist dies nicht immer so gewünscht und mir fallen drei Konstellationen ein.

  • Default: Schutz gegen anonymen Empfang
    In den meisten Fällen ist die Schutzfunktion sinnvoll. Wäre schon blöde, wenn so eine Gruppenadresse auch noch in Spam-Verteilern auftaucht und der Spammer damit gleich sehr viele Empfänger erreicht.
  • Interner anonymer Empfang
    Oft gibt es aber den Bedarf, dass interne Absender, die sich nicht authentifizieren, eine Gruppe erreichen sollen. Klassisches Beispiel ist das Monitoring (Nagios, PRTG und Co) oder Systemmeldungen, die nicht nur an eine Person, sondern einen Verteiler gesendet werden sollen. Ich bin zwar weiterhin kein Freund davon, eine Mail an mehrere Personen zu senden und damit zu multiplizieren. Schließlich muss jeder Empfänger die Mail selbst lesen und löschen und sich ggfls. mit den anderen Empfängern abstimmen. Für wichtige Benachrichtigungen ist es dennoch ein häufiger Fall. Ich hoffe dann einfach, dass die Empfänger nicht auf die Mail antworten sondern im Quellsystem die Ursache beheben. Netter wäre es natürlich, wenn das System selbst wüsste, welche Benutzer gerade in der Verantwortung stehen und diese gerichtet anschreibt.
  • Externer Anonymer Emfpang
    Sie glauben gar nicht, wie viele Firmen zentrale Mailadressen wie "vertrieb@" oder "Support@" oder "Bewerbung@" immer noch über einen Verteiler abwickeln. Ich kann ja verstehen, dass man so sicherstellen will, dass sich hoffentlich jemand um die Mail kümmert. Aber eine "Shared Mailbox" ist fr so etwas meiner Ansicht nach immer noch besser. Gegen das "Vergessen" von Mail in so einer Mailbox kann man ja durchaus andere Methoden entwickeln, z.B. die ungelesenen Mails per Skript oder Monitoring überwachen und ggfls. zu eskalieren. Oder sie klemmen direkt ein CRM-System dahinter, welches ihnen noch mehr Möglichkeiten bietet.
    Wenn das aber alles nicht gewollt ist, dann können Sie die Gruppe auch "anonym" erreichbar machen. Sobald die Adresse aber z.B. bei "bewerbung@" auf einer Webseite erscheint, ist ein guter Spamfilter wirklich wichtig.

Leider kann Exchange nicht einfach unterscheiden, ob eine Mail nun aus dem Internet anonym eingeliefert wird oder von einem internen System. Natürlich können Sie die internen IP-Adressen über einen Empfangsconnector qualifizieren aber die Mail bleibt anonym. Im Fall von zentralen Systemen wie einem Helpdesk, ERP-System oder Monitoring sollten Sie daher genau überlegen, ob diese Systeme nicht einfach "authentifiziert" senden können. Dann sind all die Probleme deutlich reduziert.

Benutzer

Etwas anders sieht es bei Benutzern aus. Auch gibt es die Möglichkeit den Empfang von anonymen Absendern zu unterbinden. Allerdings nutzen wohl die wenigsten Firmen diese Option. Ein neu angelegter Benutzer hat folgende Einstellungen hinsichtlich der Nachrichtenzustellung:

In der Exchange PowerShell heißt das Feld bei dem Postfach genau wie bei der Gruppe.

Get-mailbox | ft name,primarysmtpaddress,RequireSenderAuthenticationenabled

Name                      PrimarySmtpAddress                     RequireSenderAuthenticationEnabled
----                      ------------------                     ----------------------------------
Systemingenieure          systemingenieure@uclabor.de                                         True

Allerdings sehen sie in der GUI, das es hier noch weitere Optionen gibt, z.B. um den Empfang nur auf bestimmte Absender zu beschränken oder Absender zu blocken. Diese Listen sind nur durch den Administrator zu pflegen und werden daher eher selten genutzt. Ich kenne Fälle, in denen z.B. der CIO neben seinem öffentlichen Postfach, welches durch das Vorzimmer betreut wird, noch ein zweites geheimes Postfach hat. Dieses ist quasi verborgen und soll auch nur bestimmten Personen zugänglich sein. Das sind aber eher suspekte Konfigurationen. Zumindest im inneren Verkehr sollte ein CxO froh sein, wenn vielleicht ein Mitarbeiter eine Situation direkt an den üblichen Hierarchien vorbei schildern möchte.

Nicht alle menschlichen Probleme lassen sich durch Technik lösen. Bei internen Mails ist der Absender ja bekannt und wer sich von jemandem "gestört" fühlt, sollte vielleicht ein persönliches klärendes Gespräch nutzen.

Es gibt aber einen anderen Fall, an dem diese Funktion durchaus interessant ist. Sie können So natürlich scher schnell den Empfang von Mails aus dem Internet oder anonymen internen Absendern unterbinden ohne die interne Kommunikation zu stören. Das kann für restriktive Postfächer, z.B. minderjähigen Auszubildenden genauso relevant sein wie externen Mitarbeitern, die ein internes Postfach nur für die interne Kommunikation haben. Wobei dieser Schalter nicht den Versand von Mails verhindert.

Auch das LDAP-Feld ist mit den Gruppen identisch

msExchRequireAuthToSendTo: TRUE

Insofern ist dieses Feld für eine weitere Filterung wichtig

Bedeutung für Spamfilter

Kaum jemand wird heute einen Exchange Server mit Port 25 aus dem Internet erreichbar machen. Früher hatte Exchange gar keinen Filter aber die Spam-Mails waren auch noch in der Unterzahl. Mit der Zunahme von Spam-Mails hat Microsoft in Exchange einen Spamfilter addiert, der aber nie die Leistung kommerzieller Lösungen erreicht hat. Viele Firmen haben von jeher schon ein Problem damit, Exchange so nahe ans Internet zu stellen und entsprechende Relais-Systeme zwischen Exchange und Internet platziert. Mittlerweile hat Exchange On-Premises nur noch einen sehr rudimentären Filter, der eigentlich als "nicht vorhanden" bezeichnet werden sollte. Allenfalls als Virenfilter dürfte er noch durchgehen. Aber Microsoft hat sowieso andere Pläne mit Exchange. Über Office 365 gibt es mit "Exchange Online Protection" einen gehosteten Spamfilter, der On-Premises-Umgebungen absichern kann. Zudem schützt die gleiche Lösung natürlich auch Exchange Online Konten. Es dürfte mit Exchange 2019 klar sein, dass Microsoft den Betrieb von lokalen Exchange Servern bei Kunden nur noch bei größeren Firmen für sinnvoll ansieht und alle anderen Firmen besser auf Office 365 setzen sollten.

Es wird aber sicher noch viele Jahre dauern und selbst dann bin ich nicht sicher, ob es so kommen wird. Wenn Sie aber ihre eigenen Exchange-Server betreiben, dann sollten Sie dem vorgelagerten System die Information geben, welche Empfänger überhaupt anonym erreichbar sind. Leider lehnt Exchange eine eingehende Mail an so einen beschränkten Empfänger nicht direkt auf SMTP-Level ab, sondern nimmt die Mail dennoch erst an und versenden dann einen NDR. Ich habe dazu testweise intern per TELNET eine Mail an Exchange 2016 gesendet. Sie wurde angenommen aber später habe ich den folgenden NDR bekommen

Sie sehen gut die Beschreibung

Remote Server returned '550 5.7.134 RESOLVER.RST.SenderNotAuthenticatedForMailbox; authentication required; 
Delivery restriction check failed because the sender was not authenticated when sending to this mailbox'

Eine zweite Herausforderung ist, dass so ein hinsichtlich des Empfangs beschränktes Postfach natürlich problemlos Mails in das Internet versenden kann. Nun gibt es viele Firmen, die mit einer "noreply@"-Adresse versenden und damit kenntlich machen wollen, dass Sie gerne senden aber eine Rückmeldung ihnen unwichtig ist. Ich weiß nicht, wie Sie damit umgehen, aber mich interessieren diese Mails dann auch nicht mehr. Warum soll nur mein Gegenpart von den Kosteneinsparungen bei Mails profitieren.

Ich vertrete also den Standpunkt dass eine Mailadresse, die Nachrichten versendet, auch die Rückläufer annehmen und verarbeiten muss. Bei Newslettern ist es nicht ungewöhnlich dass 5-20% der eingeschrieben Adressen schon gar nicht mehr gültig sind. Als Versender möchte ich dies schon wissen und den eigenen Datenbestand aktuell halten. Aber so denken nicht alle Absender.

Damit bleibt natürlich die Aufgabe, den Versand ebenfalls zu unterbinden.

Zumindest der Empfang von Mails an Adressen, die nicht anonym erreichbar sind, müssen Sie möglichst früh unterbinden. Aus meiner Sicht muss da System, welches die Mails über den MX-Record bekommt, diese Empfängerprüfung durchführen und nicht erlaubte Empfänger permanent ablehnen. Nur so verhindern Sie zuverlässig, dass sie solche Mails annehmen und Exchange einen NDR an den vermutlich gefälschten Absender zurücksenden. Siehe dazu auch NDR-Backscatter Die meisten Produkte erlauben heute schon einen LDAP-Import von gültigen Mailadressen von einem internen System in irgendeiner Weise. Prüfen Sie, ob sie den Filter auf das Attribut (msExchRequireAuthToSendTo=TRUE) erweitern können. Es ist wichtig, dass "TRUE" in Großbuchstaben gesetzt ist

Beim Versand könnten Sie auch die Filterfunktionen von Exchange nutzen. Das ist aber auch ein Konfigurationsschritt mehr. Ideal wäre es, wenn der Spamfilter auch ausgehende Mails auf Mails und Spam überprüft. Es soll ja durchaus schon vorgekommen sein, dass eine Firma sich über einen anderen Weg einen Schädling eingefangen hat, der dann von innen heraus aktiv geworden ist. So kann die Reputation eines Mailservers und seiner IP-Adressen (Siehe Spam und UCE - Filter: Relay Block List) ganz schnell verloren. Da das Relais-System ja alle gültigen Benutzer kennt, ist es einfach, hier solche Absender ausgehende zu blocken.

Weitere Links