E2013 Recipient Filter
Die Empfängerfilterung gibt es mit Exchange 2013 natürlich immer noch aber durch die Veränderungen der Rollen prüft nun die Mailbox Transport-Rolle die Empfänger und nicht mehr die CAS-Rolle, welche einfach nur die SMTP-Verbindung als Proxy transparent durch leitet.
Entsprechend übernimmt der Transportdienst auf der Mailboxrolle die Aufgabe die Empfänger gemäß der Konfiguration zu überprüfen und gegebenenfalls abzulehnen. Bislang ist die Ablehnung von ungültigen Empfängern schon während des Empfangs der effektivste und sicherste Weg, Mails ohne gültigen Empfänger zu behandelt. Denn meist ist es "Spam", den man eh nicht empfangen will und wenn Sie eine Mail schon mal angenommen haben, dann müssen sie formal auch eine Unzustellbarkeit versenden. Das wollen Sie sicher nur für gültige Absender machen, um nicht selbst als Störer in Erscheinung zu treten.
Default Einstellung
Bei Exchange 2010 gab es noch die "Edge-Rolle" als erstes System, welches z.B. in einer DMZ die Mails angenommen und gefiltert hat. Ich habe aber nur ganz wenige Firmen können gelernt, die Exchange Edge tatsächlich installiert haben. Oft wurden andere leistungsfähigere Relay-Systeme genutzt (z.B. NoSpamProxy oder andere). Aber gerade kleine Firmen haben auch gerne den Exchange 2010/2007 Server direkt per NAT auf Port 25 erreichbar gemacht. Dann konnten damals die AntiSpamAgents installiert werden, um eine Empfängerfilterung auch auf der normalen Hub/Transport-Rolle zu ermöglichen. Bei Exchange 2013 gibt es die "Edge-Rolle" nicht mehr aber dafür gibt es eine Empfängerfilterung in der globalen Konfiguration. Die Default-Werte sind:
[PS] C:\>Get-RecipientFilterConfig
RunspaceId : 8aa39e35-58d8-4113-9f97-00328b1a5d66
Name : RecipientFilterConfig
BlockedRecipients : {}
RecipientValidationEnabled : False
BlockListEnabled : False
Enabled : True
ExternalMailEnabled : True
InternalMailEnabled : False
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=RecipientFilterConfig,CN=Message Hygiene,CN=Transport Settings,
CN=First Organization,CN=Microsoft Exchange,
CN=Services,CN=Configuration,DC=lab2013,DC=msxfaq,DC=net
Identity : RecipientFilterConfig
Guid : bd5eb58b-a5a4-48f1-acec-38906a0be54c
ObjectCategory : lab2013.msxfaq.net/Configuration/Schema/
ms-Exch-Message-Hygiene-Recipient-Filter-Config
ObjectClass : {top, msExchAgent, msExchMessageHygieneRecipientFilterConfig}
WhenChanged : 28.10.2012 23:06:49
WhenCreated : 28.10.2012 23:06:49
WhenChangedUTC : 28.10.2012 22:06:49
WhenCreatedUTC : 28.10.2012 22:06:49
OrganizationId :
OriginatingServer : DC.lab2013.msxfaq.net
IsValid : True
ObjectState : unchanged
Wenn Sie die Ausgabe analysieren, dann sehen Sie, dass die Empfängerprüfung (RecipientValidationEnabled:$False)abgeschaltet ist.
Schade, dass Microsoft an
vielen Stellen sinnvolle Default-Werte
angenommen hat aber hier aus meiner Sicht besser
ein "$True" gesetzt hätte. Warum sollte Exchange
Mails an ungültige Adressen per Default annehmen
(und an die vielleicht gefälschte oder ungültige
Absenderadresse einen NDR senden ?.
Nur wenn Exchange ungültige Mails an z.B. ein
anderes System weiter leiten würde (Eimerkette
bzw. Kaskade), dann macht diese Einstellung
überhaupt Sinn.
Ich plädiere daher natürlich dafür, ungültige
Empfänger umgehend schon beim "RCPT TO" zu
blockieren!
- Get-RecipientFilterConfig
http://technet.microsoft.com/de-de/library/aa997924%28v=exchg.150%29.aspx
Konfiguration
Um dieses gewünschte Verhalten zu erreichen, muss die Exchange Konfiguration angepasst werden.
Hinweis:
Der Exchange 2013 Frontend ist in Bezug auf SMTP
nur ein "Proxy" auf den Backend. Alle
Filterfunktionen müssen daher auf allen Backend
Servern aktiviert werden. Der Frontend merkt
dann auch, dass er die Mail nicht los wird und
gibt die Fehlermeldung des Backend nach extern
weiter.
Die Konfiguration der Empfängerfilterung ist bei Exchange 2013 nur noch per PowerShell möglich.
Set-RecipientFilterConfig ` -Enabled $true ` -RecipientValidationEnabled $true
Das allein reicht aber noch nie ein einfacher Test beweist:
220 EX2013.lab2013.msxfaq.net Microsoft ESMTP MAIL Service ready at Sat, 17 Aug 2013 12:49:55 +0200
helo test
Zwar wird die Mail an eine fremde Domain als "Relay" erkannt und unterbunden aber der gültige und der ungültige Empfänger werden angenommen. Voraussetzung ist auch hier, dass die AntiSpam-Agents noch installiert werden.
[PS] C:\>cd "c:\Program Files\Microsoft\Exchange Server\V15\Scripts" [PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\install-AntispamAgents.ps1
Diesmal aber auch dem Postfach Server, denn die Hub-Transport-Rolle ist nur noch ein Reverse Proxy:
Und der Transportdienst muss natürlich noch einmal durchgestartet werden.
[PS] C:\> Restart-Service MSExchangeTransport
Die Einrichtung installiert natürlich gleich mehrere "Agenten", auch wenn wir eigentlich nur die Empfängerprüfung einrichten wollten.
[PS] C:\>Get-TransportAgent Identity Enabled Priority -------- ------- -------- Transport Rule Agent True 1 Malware Agent True 2 Text Messaging Routing Agent True 3 Text Messaging Delivery Agent True 4 Content Filter Agent True 5 Sender Id Agent True 6 Sender Filter Agent True 7 Recipient Filter Agent True 8 Protocol Analysis Agent True 9
Wer mag kann die "nicht benötigten" Agenten natürlich auch wieder abschalten.
disable-TransportAgent "Sender Filter Agent" -Confirm:$false Disable-TransportAgent "Sender Id Agent" -Confirm:$false Disable-TransportAgent "Content Filter Agent" -Confirm:$false Disable-TransportAgent "Protocol Analysis Agent" -Confirm:$false
Alternativ starten Sie "Uninstall-AntispamAgents.ps1" und bestätigen das Entfernen nur für diese Agenten.
Wer mal in das Script-Verzeichnis schaut, findet eine ganze Menge von PowerShell-Scripts rund um das Thema Antispam.
[PS] C:\>dir "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\*anti*.ps1"
Directory: C:\Program Files\Microsoft\Exchange Server\V15\Scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 21.09.2012 11:26 10177 AntispamCommon.ps1
-a--- 01.10.2012 11:35 11645 Disable-AntimalwareScanning.ps1
-a--- 01.10.2012 11:35 14043 Enable-AntimalwareScanning.ps1
-a--- 21.09.2012 11:26 12521 get-AntispamFilteringReport.ps1
-a--- 21.09.2012 11:26 11359 get-AntispamSCLHistogram.ps1
-a--- 21.09.2012 11:26 12459 get-AntispamTopBlockedSenderDomains.ps1
-a--- 21.09.2012 11:26 11499 get-AntispamTopBlockedSenderIPs.ps1
-a--- 21.09.2012 11:26 12214 get-AntispamTopBlockedSenders.ps1
-a--- 21.09.2012 11:26 11417 get-AntispamTopRBLProviders.ps1
-a--- 21.09.2012 11:26 11514 get-AntispamTopRecipients.ps1
-a--- 21.09.2012 11:26 14625 install-AntispamAgents.ps1
-a--- 21.09.2012 11:26 10801 Reset-AntispamUpdates.ps1
-a--- 21.09.2012 11:26 12181 uninstall-AntispamAgents.ps1
Es ist also noch alles da, war wir auch von Exchange 2010 schon kannten.
Kontrolle
Nun sollte natürlich kontrolliert werden, ob die Einstellungen wirken und daher wenden den gleichen Test mit einem leicht angepassten Betreff erneut an:
Was fällt ihnen auf ?. Exchange akzeptiert scheinbar die Mail an "invalid@lab2013.msxfaq.net", obwohl er sie hier schon ablehnen könnte. Stattdessen kann der Sender die komplette Mail einliefern. Das können durchaus einige Megabyte sein. Aber dann bekommt der Absender am Ende ein "550 5.1.1 User unknown" und quittiert die Mail komplett als unzustellbar.
Ich wollte es erst nicht glauben, da es für dieser Verhalten aus meiner Sicht keine rationale Begründung geben kann. Es macht keinen unterschied, ob der Transport schon beim "RCPT TO" den Empfänger prüft oder erst danach. Prüft er vorher, dann kann er sich bei eine Mail mit nur diesem einen Empfänger sogar den kompletten Empfang der Restinformation sparen.
Although the Recipient
Filter agent is available on Mailbox servers,
you shouldn't configure it. When recipient
filtering on a Mailbox server detects one
invalid or blocked recipient in a message that
contains other valid recipients, the message is
rejected.
Quelle:
https://technet.microsoft.com/en-us/library/bb125187(v=exchg.150).aspx
Das Problem bei diesem Verhalten ist natürlich, dass der sendende Mailserver nicht erkennen kann, welcher Empfänger aus der Liste nun ungültig ist und dass die komplette Mail "unzustellbar" ist. Der absendende Mailserver versucht es also nicht mehr erneut und der Absender bekommt die Information, dass alle Empfänger unerreichbar sind.
Messagetracking ist blind
Mich hat dann natürlich interessiert, ob die Mail, die zum Absender komplette mit einem "550 5.1.1 User unknown" quittiert wurde, zumindest bei den gültigen Empfängern ankommt. Da hilft dann das Messagetracking:
[PS] C:\>Get-MessageTrackingLog -Sender fra---nk@carius.de -EventId RECEIVE
EventId Source Sender Recipients MessageSubject
------- ------ ------ ---------- --------------
RECEIVE SMTP fra---nk@carius.de {invalid@lab2013.msxfaq.net, a... test1
[PS] C:\>Get-MessageTrackingLog -Sender fra---nk@carius.de -MessageSubject Test2
Hier wartet dann die zweite Überraschung. Alle Versuche eine Mail mit einem ungültigen Empfänger an Exchange zuzustellen, werden hier überhaupt nicht mehr gelistet. für den Administrator ist es per Default gar nicht mehr möglich, diese Fehlversuche auf Anhieb zu zu finden. Er muss dann schon das aufwändigere SMTP-Tracing aktivieren. Zumindest ein "FAIL" hätte der Transport-Dienst hier protokollieren können, wenn er schon sich die Mühe macht die komplette Mail zu empfangen und erst am Ende die Bestätigung abzulehnen.
So wäre es besser !
Das "normale" Verhalten zur Behandlung von ungültigen Empfängern ist eine direkte Ablehnung des Empfängers schon beim RCPT TO während der SMTP-Envelope-Übermittlung.
So kann der sendende Mailserver für jeden Empfänger erkennen, welcher der Empfänger einer Mail ungültig ist. Eine Mail an mehrere Empfänger kann so selektiv vom sendenden Mailserver zugestellt und quittiert werden.
Abhilfe
Nun ist es aber nicht so, dass Exchange es nicht könnte. Es ist nur der Frontend Service, der das per Default nicht macht. Der Backend Server aber kann schon entsprechend konfiguriert werden. Allerdings müssen Sie nun natürlich den Zugriff von extern am Frontend Server vorbei direkt auf den Backend Server leiten.
Eigentlich möchte ich nicht, dass mein Backend SMTP-Server direkt aus dem Internet erreichbar sein soll. Aus meiner Sicht ist dies der falsche Weg und die Empfängerfilterung sollte auf jeden Fall auf dem extern System aus dem Internet erfolgen. Und das ist in der Regel ein vorgeschaltetes Relay wie NoSpamProxy oder notfalls auch einen Exchange Edge Server oder einen gehosteten Spamfilter in der Cloud wie EOP u.a.
Wenn Sie dennoch die Funktion auf dem Backend aktivieren wollen, dann haben Sie weiter oben schon die Schritte gesehen, um die Funktion zu aktivieren. Dann müssen Sie nur noch zwei Dinge prüfen bzw. gleich setzen.
# Sicherstellen, dass AddressBookEnabled gesetzt ist
Get-AcceptedDomain `
| Set-AcceptedDomain `
-AddressBookEnabled $true
# Sicherstellen, dass Filterung aktiv ist.
Set-RecipientFilterConfig `
-RecipientValidationEnabled $true
Beide Werte sind per "Default" so gesetzt. Aber es könnten ja sein, dass jemand die Werte verändert hat.
Und dann gilt es die SMTP-Verbindungen auf den Backend SMTP (Port 2525) zu lenken.
- Recipient Verification with Exchange
2013 and Later
https://www.roaringpenguin.com/recipient-verification-exchange-2013 - How do I reject incoming email for
unknown Users in MS Exchange 2013?
https://support.prolateral.com/index.php?/Knowledgebase/Article/View/204/35/how-do-i-reject-incoming-email-for-unknown-Users-in-ms-exchange-2013 - Dynamic Recipient Verification using
Exchange 2013 and 2016
https://helpdesk.spamtitan.com/support/solutions/articles/4000003763-dynamic-recipient-verification-using-exchange-2013-and-2016 - Exchange Recipient Filtering not working
http://www.adnsolutions.com/exchange-recipient-filtering-not-working/ - Sophos: Recipient Verification with
Exchange 2013
https://community.sophos.com/products/unified-threat-management/f/mail-protection-smtp-pop3-antispam-and-antivirus/49446/recipient-verification-with-exchange-2013
Einschätzung
Ich habe erst einmal ungläubig nachgefragt, als ich das erste mal mit diesem neuen Verhalten konfrontiert wurde und ich kann auch immer noch nicht nachvollziehen, warum Microsoft das Default-Verhalten früherer Exchange Versionen so verschlechtert hat. Es kann sicher nicht daran liegen, weil man beim Empfang Zeit und Ressourcen sparen will. Die Gültigkeit eines Empfängers muss man immer prüfen und je früher desto besser.
Aus meiner Sicht ist die aktuelle Funktion so schlecht, dass man Exchange gar nicht mehr direkt am Internet betreiben sollte, sondern auf jeden Fall ein Relay davor stellen muss, welches ungültige Empfänger so früh wie möglich ablehnt und IP-Adressen mit allzu vielen Fehlversuchen für einige Zeit blockt. Das spart mehr Ressourcen als Mails für ungültige Empfänger verspätet abzulehnen oder sogar anzunehmen und mit einem NDR zu versehen.
Genau genommen können Sie unter diesen Vorzeichen die Empfängerfilterung nicht wirklich einsetzen. Ohne Filterung besteht die Gefahr, dass Sie mit einem NDR-Spamming bald nicht mehr mitreden dürfen (Blocklists etc.) und mit der Filterung kostet Sie dies mehr Bandbreite als erforderlich.
Weitere Links
- Directory Based Edge Blocking (DBEB) Mit der richtigen Einstellung lehnt Exchange Online auch ungültige Empfänger direkt ab.
- DBEB mit Hybrid Internal Relay macht OnPremises Empfänger erreichbar aber deaktiviert DBEB
- E2K7 Antispam
- RCPTTO
- NDR-Spamming
- MSXFAQ.DE:NoSpamProxy
- Get-RecipientFilterConfig
http://technet.microsoft.com/de-de/library/aa997924%28v=exchg.150%29.aspx - Set-RecipientFilterConfig
http://technet.microsoft.com/de-de/library/aa998613(v=exchg.150).aspx - CatchUnknown2010
- Antispamschutz
http://technet.microsoft.com/de-de/library/jj218660%28v=exchg.150%29.aspx - Empfängerfilterung
http://technet.microsoft.com/de-de/library/bb123891%28v=exchg.150%29.aspx
