CatchAll-Connector

Auf der Seite Office 365: Mail Connector habe ich etwas zum Mailrouting in der Cloud und zur Verbindung mit eigenen Servern geschrieben. Ergänzend dazu habe ich auf der Seiter Office 365:Fremdconnector beschrieben wie Drittprodukte sich an Office 365 als Connector anbinden können. Die Anbindung als Fremd-Connector mit all den zusätzlichen Herausforderungen ist auch weiterhin für Systeme erforderlich, die für sehr viel Domänen zuständig sind. Klassisch also gehostete Spamfilter, Mail-Relays etc. Wenn Sie aber nur einen Adressraum zu bedienen haben, dann kann eine Office 365 "CatchAll"-Mailbox eine Option darstellen.

Diese Seite wurde zusammen mit Ferrari Electronic bei der Planung einer Fax-Server Anbindung an Office 365 entwickelt.

CatchAll in Exchange

Exchange hatte lange Zeit von Hause aus eigentlich keine "Catch-All" Funktion. Neuere Versionen von Exchange haben beim Empfang per SMTP schon die Gültigkeit des Empfängers und andere Faktoren geprüft und Mails frühzeitig abgelehnt. CatchAll ist auch für Firmen für eine offizielle Domäne nicht wirklich sinnvoll, da sich fast ausschließlich Spam sammelt. Besser ist es immer eine Mail an eine ungültige Adresse abzulehnen, damit der Absender reagieren kann. Dennoch gibt es immer wieder die Forderung nach CatchAll, so dass auch auf der MSXFAQ einige Seiten dazu entstanden sind:

Seit Exchange 2013 und Exchange Online (Office 365) ist es über Transportregeln sehr einfach, Mails an bestimmte Domänen in ein Sammelpostfach ablegen. Das Postfach ist dabei ein "ganz normales" Postfach, welches nur als Ziel in einer Transportregel genutzt wird.

Zustellung über CatchAll-Regel

Die Einrichtung der Transportregel ist nicht schwer, wenn Sie beim ersten Schritt aufpassen.

Diese Funktion ist ein Exchange 2013 OnPremise als auch mit Exchange Online möglich.

Im Exchange Control Panel können sie eine Regel anlegen aber hier müssen Sie unten den Link "Weitere Optionen" anklicken:

Erst dann erscheinen im Regelassistenten auch die Optionen eine komplette Domäne umzuleiten:

Vergessen Sie bei der Angabe der Domäne nicht das "Plus" zu drücken, damit die Domäne auch übernommen wird. Als Aktion geben Sie dann an, dass die Mails an einen Empfänger weiter geleitet werden:

Das ist in meinem Beispiel dann ein Postfach in Office 365. Es kann aber auch Connector sein. Auch ohne externen MX-Record und selbst ohne den Eintrag einer autoritativen Domäne landet nun jede Mail an diese Domäne in dem vorgegeben Postfach.

Das ganz ist natürlich auch per Exchange PowerShell möglich 

$UserCredential = Get-Credential 
$Session = New-PSSession `
   -ConfigurationName Microsoft.Exchange `
   -ConnectionUri https://outlook.office365.com/PowerShell-liveid/ `
   -Credential $UserCredential `
   -Authentication Basic `
   -AllowRedirection 
Import-PSSession $Session

New-TransportRule `
   -Name "Reroute outgoing fax" `
   -ExceptIfFromScope NotInOrganization `
   -RecipientDomainIs "fax.msxfaq.net" `
   -StopRuleProcessing $true  `
   -RedirectMessageTo "fax@msxfaq.net"

Remove-PSSession $Session 

Der Parameter "-ExceptIfFromScope NotInOrganization"  verhindert, dass die Regel auch für Mail von Extern angewendet wird. Ein "Offenes Relay" zu unserem Gateway sollen wir ja nicht sein.

Interessanterweise bleiben dabei Absender als auch Empfänger erhalten. Die Kopfzeilen zeigen, dass die "To-Zeile" bestehen bleibt.

Received: from DB3PR01MB266.eurprd01.prod.exchangelabs.com (10.141.4.17) by
 DB3PR01MB265.eurprd01.prod.exchangelabs.com (10.141.4.15) with Microsoft SMTP
 Server (TLS) id 15.1.213.10 via Mailbox Transport; Thu, 9 Jul 2015 12:21:25
 +0000
Authentication-Results: fax.carius.de; dkim=none (message not signed)
 header.d=none;
Received: from DB3PR01MB265.eurprd01.prod.exchangelabs.com (10.141.4.15) by
 DB3PR01MB266.eurprd01.prod.exchangelabs.com (10.141.4.17) with Microsoft SMTP
 Server (TLS) id 15.1.213.10; Thu, 9 Jul 2015 12:21:19 +0000
Received: from DB3PR01MB265.eurprd01.prod.exchangelabs.com ([10.141.4.15]) by
 DB3PR01MB265.eurprd01.prod.exchangelabs.com ([10.141.4.15]) with mapi id
 15.01.0213.000; Thu, 9 Jul 2015 12:21:20 +0000
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: "Carius, Admin (O365 Carius)" <admin@carius.onmicrosoft.comm>
To: "123@fax.carius.de" <123@fax.carius.dee>
Subject: Test ausgehendes Fax
Thread-Topic: Test ausgehendes Fax
Thread-Index: AQHQukHCOfk74PA9Ok2bnUB66CtI+A==
Date: Thu, 9 Jul 2015 12:21:19 +0000
Message-ID: <DB3PR01MB265EF4DF4EBD00AAC9179229E900@DB3PR01MB265.eurprd01.prod.exchangelabs.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: <DB3PR01MB265EF4DF4EBD00AAC9179229E900@DB3PR01MB265.eurprd01.prod.exchangelabs.com>
MIME-Version: 1.0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-AuthSource: DB3PR01MB265.eurprd01.prod.exchangelabs.com
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-Originating-IP: [79.196.167.84]
X-MS-Exchange-Organization-Network-Message-Id: 00aec2f6-fe0e-4bdc-f1a8-08d28858e58f
Return-Path: admin@carius.onmicrosoft.comm
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB266;
X-MS-Exchange-Organization-AVStamp-Service: 1.0
DB3PR01MB266: X-MS-Exchange-Organization-RulesExecuted
X-MS-Exchange-Transport-Rules-Loop: 1
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(3002001);SRVR:DB3PR01MB266;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB266;
X-Forefront-Antispam-Report: SFV:SKI;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:DB3PR01MB266;H:DB3PR01MB265.eurprd01.prod.exchangelabs.com;FPR:;SPF:None;LANG:;
SpamDiagnosticOutput: 1:0
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2015 12:21:19.9295
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: eef62a09-7718-4063-82db-d7582dc8916f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR01MB266
X-MS-Exchange-Transport-EndToEndLatency: 00:00:05.7188416
X-Microsoft-Exchange-Diagnostics:
	1;DB3PR01MB266;2:uHl++JYqXxxx==
X-Microsoft-Exchange-Diagnostics:
	1;DB3PR01MB266;4:KezCcml5cxxx==
X-Microsoft-Exchange-Diagnostics:
	1;DB3PR01MB265;9:JSPOywZuxxxx

Die Mail selbst ist unverändert, d.h. Betreff, Body aber auch Anlagen kommen unverändert durch.

Zugriff als Gateway

Natürlich muss so ein Sammelpostfach auch "gelesen" werden. für automatische Prozesse ist natürlich EWS der präferierte Weg. CDO ist mit Exchange 2013 quasi "auslaufend" und RPC/HTTP oder MAPI/HTTP sind mit Outlook kein Problem, aber Outlook zu automatisieren ist sicher nichts für den Dauerbetrieb. Dafür ist EWS viel besser geeignet, zumal es durch die konsequente Nutzung von HTTPS (444/TCP) sehr viel flexibler (Stichwort Firewall, Ports, Proxy, Betriebssysteme) ist.

Per EWS kann eine Software eines Drittherstellers nicht nur das Sammelpostfach lesen und leeren, sondern auch das Adressbuch lesen und damit das Azure AD indirekt als Quelle für Stammdaten wie Mailadresse und z.B. Faxnummer nutzen.

Geht die Lösung einen Schritt weiter und aktiviert Sie die "EWS Impersonation", dann kann die Drittsoftware mit dem Konto des Sammelpostfachs sofort direkt in die Postfächer der Anwender schauen und schreiben. für einen einfachen Fax-Service ist dies sicher nicht interessant, wohl aber für eine UC-Lösung, die mit dem Zugriff auf das Postfach weitere Dienste (VoiceMail, Mailvorlesen etc.) anbietet. Allerdings ist das Impersonation-Konto dann natürlich ein sicherheitstechnisch sehr sensibles Konto.

Über den EWS-Zugriff auf das Sammelpostfach kann ein Dienst alle Mails an dieses Postfach abholen als auch nach Personen suchen. Das erspart eine Abhängigkeit von einem lokalen Active Directory oder die Nutzung von Azure AD-PowerShell oder Azure AD GraphAPI mit Anmeldedaten.

Wenn der Dienst nicht "pollen" sondern umgehen auf neue Elemente reagieren soll, dann kann er eine EWS-Push-Benachrichtigung implementieren.

Allerdings sollten abgeholte und verarbeitete Mails im Postfach nicht einfach in den Papierkorb sondern permanent gelöscht werden. Nicht dass die "Deleted Items" den Postfach überquellen lassen.

Zustellung zum Benutzer

Wenn ein Gateway oder ein Dienst über ein Sammelpostfach Informationen entgegen nimmt, dann wird es früher oder später auch einen Rückweg zum Absender benötigen. Auch hier gibt es zwei bzw., drei Optionen:

  • Versand per SMTP
    Der einfachste und flexibelste Versand eine Meldung an so einen Absender ist natürlich eine SMTP-Verbindungen. Wer beliebige Absender verwenden will, sollte sich nicht authentifizieren, damit Exchange nicht die Absenderadresse ersetzen. Um etwaige Spamfilter zu umgehen, sollte die Sender-IP, z.B. ihre öffentliche IP des Service in Exchange als vertrauenswürdig konfiguriert werden. Das geht am einfachsten über einen Receive-Connector. Eine Verschlüsselung ist per SMTP/TLS möglich.
  • Versand per EWS
    Wer den Umweg per SMTP scheut, kann natürlich über EWS einfach eine Mail in den Postausgang des CatchAll-Postfachs legen. Dies ist dann eine authentifizierte und verschlüsselte Verbindung. Allerdings ist damit der Absender vorgegeben, was z.B. bei einer Anbindung an einen fremden Adressraum wie FAX nicht hilfreich ist.
  • "Ablegen" per EWS Impersonation 
    Wenn das Dienstkonto die Impersonate-Rechte hat, kann es natürlich auch einfach per EWS direkt in das Postfach zugreifen und die gewünschte Information als neues Element im Posteingang anlegen. Allerdings ist die Mail dann nicht "zugestellt" worden, was je nach Client nicht immer eine "Neue Mail angekommen"-Meldung generiert.

Bei Betrachtung der drei Optionen wird es wohl darauf hinauslaufen, die neuen Elemente einfach per SMTP an das Postfach zuzustellen.

Beifang

Diese "CatchAll-Mailbox" bekommt natürlich nicht zwingend nur Mails mit der per Transport-Regel umgeleiteten Mails. Sie hat natürlich auch so eine "normale Mailadresse" und wenn Sie nicht in der GAL ausgeblendet wurde, ist sie auch noch dort sichtbar. Ein Gateway sollte also immer damit umgehen, dass in diesem Postfach auch einmal Irrläufer gelandet sind und diese dann bestimmungsgemäß verarbeiten.

Zwei Kriterien können Sie für solche Mails anlegen

  • Absender ist extern
    Es lässt sich recht einfach ermitteln, ob der Absender in der gleichen Exchange-Organisation ist oder die Mails aus dem Internet per SMTP zugestellt wurde. Dazu kann der Absender dienen. Ersatzweise könnte auch ein "SCL=-1" darauf hinweisen oder ein SMTP-Header "X-MS-Exchange-Organization-AuthAs: Internal" gesucht werden
  • Format der Zieladresse
    Wenn das Ziel z.B. <rufnummer>@fax.msxfaq.net ist, dann ist dieser in der Regel nicht aus dem Internet zu erreichen (Kein MX-Eintrag oder komplett interne Domäne). Eine direkt an das Postfach adressierte Mail hat aber eine andere Adresse. Wobei das kein 100%tiger Schutz ist.

Entsprechend können dies diese Mails ...

  • Direkt Löschen
    Wenn Sie sehr sicher sind solche "Falsch-Mails" zu erkennen, dann können Sie diese einfach löschen
  • NDR an Absender
    Sie könnten diese Mails aber auch mit einer Antwort zurücksenden. Dann würden zumindest "echte" Absender ihren Fehler bemerken. Allerdings gibt es auch einen Störungspotential
  • Auslesen und als "Fehler loggen"
    Sie können die Mail per Gateway auch einfach auslesen und so behandeln, als wäre sie korrekt aber dann in dem Protokoll des Gateway als "Fehler" hinterlegen. Bei einem Faxserver wäre dies dann einfach vergleichbar mit einem Fax an eine ungültige Nummer.
  • Weitergeben an "Manager"
    Wenn Sie einen "Überwacher" definiert haben, dann könnten Sie solche Irrläufer zur weiteren Klärung natürlich auch dort hin weiter leiten.

Auf jeden Fall sollten Sie einen Vorgang definieren und diese Mails nicht im Postfach "liegen" lassen. Das verzögert die weitere Verarbeitung von legitimen Nachrichten.

Health Check

Exchange 2013 macht es dem E2013:Heathcheck vor. Unter dem Begriff "Managed Availability" prüft ein Service regelmäßig die Funktionsfähigkeit von Exchange und startet ggfls. Dienste oder sogar den Server durch oder liefert zumindest Meldungen im Eventlog und entsprechende Anfragen auf HTTP-Checks eines Loadbalancers.

Was Exchange billig ist, sollte ihrem Service gerade recht sein, denn mit der hier umgesetzten Anbindung per SMTP-Versand und EWS-Abholung ist es natürlich ein Leichtes, einen einfachen Funktionstest mit einzubauen.

Stellen Sie sich vor ihr Service sendet einfach alle 5 Minuten eine speziell präparierte Mail per SMTP (mit Authentifizierung um als "intern" zu gelten) oder EWS an sich selbst. Wenn er dann nicht nach spätestens einigen Sekunden diese Mail in seinem Sammelpostfach wieder findet, dann stimmt etwas nicht mit der Anbindung.

Bewertung

Gegenüber der Anbindung per Office 365: Mail Connector oder Office 365:Fremdconnector hat die Verwendung der CatchAll-Funktion von Exchange 2013 für bestimmte Fälle deutliche Vorteile. Der Mailabruf ist per HTTPS verschlüsselt und der Dienst selbst muss nicht unter eine festen IP-Adresse oder einem Namen erreichbar sein. Es muss nicht mal ein Port oder Service eingehend zu ihrem Service veröffentlicht werden. Damit umgeht eine Software die ganze Problematik der "Härtung" gegen andere Internetangriffe.

Zudem ist die Einrichtung in Exchange und Office 365 seht einfach und sogar per Browser oder PowerShell möglich.

Allerdings gibt es keine klassische "Queue", die ggfls. überwacht werden kann. Alle Elemente in Richtung des Service liegen in einem Postfach. Wer aber schon viele Jahre Exchange macht, wird sich daran erinnern, dass auch unter Exchange 4.0-5.5 die Gateways zu MS-Mail, GroupWise, cc:Mail und sogar SMTP und Dritthersteller (FFAPI) über Connector-Mailboxen angebunden wurden und der X.400-MTA die Mails an diese "fremde Adressen" auch einfach nur eine einem bereitgestellten (unsichtbaren) Postfach abgelegt und und abgeholt hat. Insofern kann ist erst mal keine großen Nachteile dieser Technik sehen.

Vielleicht würde ich über diese Anbindung per Postfach nicht gerade eine XXL-Firma mit sehr vielen Mails an Exchange anbinden. Schließlich laufen all diese Mails durch ein Postfach mit "gelöschten Objekten".

Weitere Links