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!

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
250 EX2013.lab2013.msxfaq.net Hello [192.168.0.131]
mail from:fra---nk@carius.de
250 2.1.0 Sender OK
rcpt to:invalid@msxfaq.de
550 5.7.1 unable to relay
rcpt to:invalid@lab2013.msxfaq.net
250 2.1.5 Recipient OK
rcpt to:administrator@lab2013.msxfaq.net
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject: test1

test1
.
250 2.6.0 <27790901-c568-4d47-b5e5-5f935d199678@EX2013.lab2013.msxfaq.net>
  [InternalId=11987253723137] Queued mail für delivery

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:

220 EX2013.lab2013.msxfaq.net Microsoft ESMTP MAIL Service ready at Sat, 17 Aug 2013 13:03:17 +0200
helo test
250 EX2013.lab2013.msxfaq.net Hello [192.168.0.131]
mail from:fra---nk@carius.de
250 2.1.0 Sender OK
rcpt to:invalid@msxfaq.de
550 5.7.1 unable to relay
rcpt to:invalid@lab2013.msxfaq.net
250 2.1.5 Recipient OK
rcpt to:administrator@lab2013.msxfaq.net
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Test2

Test2
.
550 5.1.1 user unknown

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.

Und schlimmer noch: Nur weil vielleicht ein Empfänger nicht mehr gültig ist, kommt die Mail bei keinem der anderen gültigen Empfänger an.

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.

telnet ex2010.msxfaq.de 25
220 ex2010.msxfaq.de Microsoft ESMTP MAIL Service ready at Tue, 07 Jun 2013 18:03:40 +0100
helo mailsender.msxfaq.de 
250 xxxxxxx Hello [192.168.100.1]
mail from:<frank.carius@netatwork.de>
250 2.1.0 Sender OK
rcpt to:<validuser@msxfaq.de>
250 2.1.5 Recipient OK
rcpt to:<invaliduser@msxfaq.de>
550 5.1.1 Invalid Recipient

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.

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 (Blacklists etc.) und mit der Filterung kostet Sie dies mehr Bandbreite als erforderlich und

Weitere Links