Prolog:

Bei diesem Kundensystem handelt es sich um eine Exchange 2013 Umgebung mit mehreren MultiRole Servern in einer DAG.
Es gibt einen Send Connector zu einer MTA Infrastruktur mit mehreren MTAs. Dabei wird die VIP der MTA Infrastruktur angesprochen.

Ausgangslage:

Bei der Umgebung  stellten wir fest, dass vermehrt E-Mails mit dem folgenden SMTP Error in den Queues stecken bleiben.

Es bleiben bei allen Servern Mails in der SmartHost Queue stecken – das Problem scheint also durch den Smarthost verursacht zu werden.

Die meisten E-Mails werden jedoch erfolgreich verarbeitet (von und zu der MTA Infrastruktur).

 Überprüfung:

Mit folgendem Befehl habe ich mir die relevanten Informationen der E-Mails aus den Queues ausgelesen.

Ich habe die Mails ebenfalls zur weiteren Analyse aus der Queue exportiert (Betrachtung eines Mails via Outlook kann durchaus einiges vereinfachen – Headerinformationen des Mails, Auflistung Empfänger etc.)

Ausser der grossen Empfängeranzahl (bis zu 150 Empfänger) konnte ich jedoch keine ungewöhnlichen Informationen im E-Mail identifizieren.

Somit prüfte ich die erlaubten Limiten

Kann also nicht das Problem sein.

Für diejenigen die sagen, es gibt doch noch eine Stelle um die MaxRecipients einzuschränken. Genau, nur wurde das Message bereits angenommen durch den Receive Connector – so dass dieses Limit nicht zutreffen kann. Geprüft werden könnte das Limit mit folgendem Befehl, für diejenigen die es dennoch lieber geprüft haben (Ich hab die ReceiveConnector in dem Befehl nicht gefiltert – sry, zu lacy – welcher ReceiveConnector zur Anwendung kommt, könnte aus dem Get-Message Befehl ausgelesen werden – Attribut: MessageSourceName).

Der Verdacht scheint sich zu bestätigen, dass das Problem auf dem SmartHost zu suchen ist.
Die Abklärungen mit den Kollegen beim SmartHost ergibt schlussendlich folgendes Bild.

Der TCP Trace zeigt, dass der Exchange Server versucht das Mail beim MTA zu deponieren, entsprechende SMTP Kommunikation ist ersichtlich.

Auf den ersten Blick konnte man auch aus dem TCP Trace nicht schlauer werden. Wir bemerkten aber, dass jeweils nach dem 100sten Empfänger die Verbindung getrennt wurde. Dies löste Verwunderung aus, da nach unserem Wissensstand keine Filterregeln oder ähnliches zwischen der Verbindung aktiv sein sollte.

Lösung:

Wir mussten leider feststellen, dass unser Wissensstand nicht korrekt war. Der Kunde hat vor wenigen Tagen eine neue Cisco ASA erhalten welche per Standard das ESMTP Inspection aktiv hat.

Quelle Cisco

Wie aus dem Referenzartikel zu entnehmen:

Als wir das ESMTP Inspection auf der ASA deaktiviert haben konnten die Mails erfolgreich durch den Exchange abgearbeitet werden.

Prolog:

• Microsoft hat ein neues Mobile App für Mailzugriff veröffentlicht: Microsoft Outlook (iPhone: https://itunes.apple.com/app/id951937596) bzw. Microsoft Outlook Preview (Android: https://play.google.com/store/apps/details?id=com.microsoft.office.outlook)
• Hierbei handelt es sich um ein zugekauftes App von der Firma Acompli
• Hier kommt der springende Punkt: https://www.acompli.com/privacy-policy/

Ausgangslage:

Wer den oberen acompli Link bereits angeschaut hat stiesst auf folgende Aussage:

What information do we collect and why?
Account Information. If you decide to sign up to use the service, you will need to create an account. That requires that you provide the email address(es) that you want to access with our service. Some email accounts (ones that use Microsoft Exchange, for example) also require that you provide your email login credentials, including your username, password, server URL, and server domain.

Dies wird auch vom Microsoft Supportern besätigt:
http://blogs.office.com/2015/01/29/deeper-look-outlook-ios-android/ in den Kommentaren;

Fragen von: larrycl:

In the linked blog post, it said the new Outlook app is based on the Acompli code base.
Acompli had a design issue whereby your usernames & passwords were stored on Acompli’s servers, and all your email was downloaded and cached by Acompli. This, IMHO, made Acompli a non-starter for business use, as it violated most corporate security policies.

Does the new Outlook app remove this “feature”, or will all your email still be routed through acompli/microsoft’s servers?

Antwort von Microsoft Support (Jon Orton – MSFT):

@larrycl – Yes, that architecture remains in place with the new app. It uses cloud components to improve app performance and enable some features, such as predictive search, recent attachments, and large attachment handling.

Lösung:

Überprüfung:

Wenn die Richtlinie korrekt angewendet wird, sollte die Mailbox beim versuch folgendes E-Mail erhalten:

Zusatz Info:

Benutzer die bereits das App verwenden, erhalten danach ständig die Aufforderung zur Anmeldung, die leider nicht als Fehlerhaft zurückgewiesen wird (erst bei der nächsten Aktion erneut auftaucht)
Der verdacht, dass zu diesem Zeitpunkt die Benutzerdaten bereits an die Server von acompli gesendet wurden ist jedoch gross. – Diese Lösung ist nicht mit einer MDM Lösung zu vergleichen. Ebenfalls besteht die möglichkeit, dass Personen mit der vorgänger Acompli App arbeiten. Leider konnte ich diese nicht zu 100% Identifizieren. Einzig auffälliger Eintrag konnte ich mit folgender Kombination ausfindig machen:

Ich habe dafür folgende Abfrage verwendet:

Damit die bestehenden Personen angesprochen werden können, kann mit folgenden Befehlen eine Liste mit E-Mail Adressen generiert werden.

Okay, Exchange 2007 ist hier etwas umständlich, da leider keine Liste mit Mailadressen zurück kommt – da es in meiner Exchange 2007 Umgebung zu wenig treffer gab, hab ich dann auch nicht mehr weiter geamcht.
Ebenfalls hatte ich keine Benutzer die mehrere ActiveSync Verknüpfungen mit dem App aufweisten (z.B: zweites Device), somit habe ich auf eine überprüfung nach Verdoppelung verzichtet.

Aufweichung – AllowDeviceIDs:

Es kann natürlich auch pro Mailbox die Freischaltung gemacht werden, wir kennen ja unsere Benutzer und eine wichtige Person möchte nicht auf das App verzichten. Hiermit lässt sich auch mit dem Block via ActiveSyncDeviceAccessRule das App pro Mailbox freischalten:

Aufweichung – Quarantäne:

Es kann natürlich auch anstelle des Block auch der Quarantäne-Modus verwendet werden. Dieser wird wie folgt eingestellt.

In diesem Modus kommt das ECP für die Freischaltung der Devices zum Einsatz.
Der Administrator muss somit die Anfragen der Benutzer entsprechend freischalten.
Hierfür lässt sich mit folgendem Befehl eine administrative Mailadresse erfassen, die eine jeweils ein E-Mail erhält sobald ein Device freigeschaltet werden muss.

Ansicht ECP – Admin:

Mailbenachrichtigung – Benutzer:

Ansicht ECP – Benutzer (Detail):


Status ist bereits Ok, im Detail ist jedoch der Quarantäne-Status erkennbar.

Löschen der App:

Hat man erst einmal ein Postfach mit der App synchronisiert, so wurden die Daten an die Cloud-Server übetragen. Diese bleiben dort auch nach einem löschen für eine gewisse Zeit erhalten (z.B.: Wenn von Device 1 zu Device 2 gewechselt wird, muss nicht mehr die komplette Mailbox in die Cloud übertragen werden.). Damit diese Daten ebenfalls entfernt werden sollte vor der deinstallation des Apps in den Kontoeinstellungen das Konto inkl. der Remote Daten entfernt werden.

Die Daten auf dem Mailsystem werden dabei nicht gelöscht.