CRM Mail

Diese Seite beschreibt die unterschiedlichen Ansätze, wie sie ein ERP/CRM/Newsletter/Helpdesk-System per Mail an ihre Exchange On-Premises oder Exchange Online Umgebung einbinden können.

Anbindung 1.0

E-Mail startete als Kommunikationsmittel zwischen Menschen aber sehr schnell wurde der Sender- und Empfängerkreis um Funktionspostfächer (Shared Mailbox) , z.B. für Vertrieb, Support etc., und Prozesse (z.B. Benachrichtigung von Backup, Firewall Monitoring etc., erweitert. Was liegt da ferner, als ein Dienstkonto mit Postfach und Zugangsdaten auszustatten. Das System kann dann einfach mit dieser Adresse die Mails nach intern aber auch extern versenden und ist bei bedarf auch von extern erreichbar. Es werden keine weiteren Server oder Einstellungen im Internet benötigt.

Diese Lösung hat aber auch einige Einschränkungen.

  • Exchange CAL
    Ein aktives Funktionspostfach, an dem sich ein Dienstuser anmeldet, benötigt eine Exchange Device CAL, wenn nicht alle darauf zugreifenden Benutzer lizenziert sind..
  • Polling
    Das verarbeitende System muss die Mails per POP, IMAP, EWS o.ä. immer wieder auslesen. Das erzeugt Last und führt doch zu Verzögerungen
  • Exchange Last
    Auch der Exchange Server ist eigentlich nur "Durchlaufstation" aber natürlich landet die Mail erst einmal im Postfach, produziert Transaktionsprotokolle und wird einige Minuten später doch gleich wieder gelöscht

Es gibt aber noch andere Gründe, warum diese Lösung nicht optimal ist.

  • Limitierte Mailadressen
    Ein Postfach kann bis zu 1123 ProxyAddresses bekommen aber sendet zumindest per EWS nur mit der primären Adresse. Eine "individuelle Mailadresse" pro Vorgang ist so nicht möglich. In Exchange Online gibt es als Zwischenschritt die Plus-Adressierung
  • Exchange Online Limits
    Dafür können Sie mit Exchange Online nicht beliebig viele Mails senden. Siehe dazu Exchange Online Message Rate Grenzen
  • Risiko gleiche Domain
    Wer den Aufwand einer eigenen Domain oder Subdomain scheut, sollte sich dran erinnern, dass er den Dienst dann schlecht woandershin umziehen kann.

Es gibt nun  sogar CRM-Lösungen, die sich "Vollzugriff" oder den vergleichbaren EWS und Impersonation-Zugriff geben lassen, um auch die Postfächer der Mitarbeiter nach Mails zu durchforsten, die besser ins CRM-System gehören. Einige entwickeln sogar einen TransportAgenten, um die Mails bei der Übertragen und zu klassifizieren und ins CRM zu kopieren oder zu verschieben. Solche Anbindungen funktionieren in Exchange Online natürlich nicht mehr und On-Premises gibt es Versionsabhängigkeiten, so dass diese Optionen mit Vorsicht einzusetzen sind.

Anbindung per SMTP

Wie kann man es dann besser machen? Zuerst müssen Sie an "Wachstum und Flexibilität" denken. Exchange 2016 ist ein Mailserver, der Mails an „individuelle“ Adressen zustellt und sie sollten alles daran setzen, dass ihre Firmenkommunikation von Mensch zu Mensch von automatischen Nachrichten nicht beeinflusst wird. Daher müssen aus meiner Sicht solche Dienste eine eigene Maildomain nutzen. Das machen die "Großen" übrigens auch so.

  • Amazon
  • Ebay Kleinanzeigen
  • Paypal

Diese drei Beispiele nutzen eine Subdomain zur Kommunikation mit Kunden und die Beispiele von Amazon und ebay zeigen, wie eine Kommunikation zwischen Kunde und Verkäufer über die Plattform geführt wird. Wenn Sie aber für jeden Vorgang eine eigene Mailadresse generieren, dann kann das nicht über ein Exchange Postfach funktionieren. Dann wird aber auch ihr Spamfilter mit einer Empfängerprüfung auf Probleme stoßen.

Einfachere Umgebungen können dann mit einer eigenen SMTP-Domäne der Subdomäne den Verkehr dieses "Spezialsystems" elegant routen. Das kann durchaus durch das vorhandene Antivirus-Filtersystem und sogar den Exchange Server gehen. Sie müssen ihre CRM-Lösung nur von Exchange per SMTP erreichbar machen. Ein kleiner SMTP-Server auf dem CRM System kann da ausreichen.

Selbst bei Windows 2019 ist ein "Windows SMTP-Server" als Rolle dabei und Microsoft beschreibt auch, wie dieser z.B. mit SQL zu nutzen ist. Der Windows SMTP unterstützt nämlich auch SMTPAuth, TLS u.a., was ein einfacher SMTP-Client nicht immer macht. Wenn der SMTP-Server auf ihrem CRM-System mitläuft, dann kann das CRM-System einfach über "localhost" auf den Server zum Versand zugreifen oder gleich über die "FileAPI" gehen. Beim Windows SMTP-Server gibt es ein DROP und PICKUP-Verzeichnis.

Aus Sicht von Exchange kann das System einfach als nachrangiger Mailserver mit einer eigenen Domain konfiguriert werden

Die Einrichtung als Kurzfassung:

Richtung Schritte

Eingehend

  • Internet: MX-Record für „crm.<kunde.tld>“ auf den Spamfilter leiten
  • Spamfilter nimmt Mails für die Domain an
    Ideal wäre es, wenn er von CMR natürlich auch individuelle Userparts verstehen könnte, z.B. per RegEx oder Datenbank-Lookup
  • Exchange hat die Accepted Domain “crm.<kunde>
    Es gibt aber kein Postfach und der Typ ist nicht „Autoritativ“ sondern „InternalRelay“ oder „ExternalRelay“
  • Exchange bekommt einen „SendConnector“ für den CRM-Adressrau zum Server
    Damit werden dann alle Mails an die Domain „crm.<kunde.tld>“ an das CRM-System mit dem eigenen Mailserver per SMTP gesendet
  • Der CRM SMTP-Server nimmt NUR Mails von Exchange an und sollte "gültige" Mails erkennen
    Der CRM-Server sollte also nicht von anderen Systemen erreichbar sein und "unpassende" Mails gesondert behandeln.

Ausgehend

  • CRM sendet die Mail direkt selbst per SMTP an Exchange oder überträgt die Aufgabe an den lokalen SMTP-Service (z.B. Pickup)
  • Exchange: Ein „Receive Connector“ gibt der IP-Adresse des CRM-Systems das Vertrauen "accept for Relay“.
  • Exchange stellt Mails entweder lokal zu oder sendet Sie weiter zum Relay Richtung Internet
  • Das ausgehende Relay sendet die Mails über MX-Records ins Internet.

Vielleicht ist es aber auch ratsam, so eine Massenkommunikation an der kompletten Exchange Plattform vorbei zu betreiben.

Durch die Nutzung einer eigenen Subdomain steht natürlich auch einer Auslagerung des Service in die Cloud nichts entgegen. Wenn Sie einen ganz pfiffigen Mailserver selbst schreiben, dann könnte er beim Empfang einer Mail schon den User-Part der Zieldresse prüfen und Mails ohne Bezug sogar direkt ablehnen.

Eine solche Lösung habe ich in ähnlicher Form schon für eine Firma damals auf Basis von Windows 2003 gebaut, wo der Windows SMTP-Server die Mail angenommen und nach "DROP" gelegt hat und dann ein VBScript damals die Mail gelesen, den Inhalt auf Plausibilität geprüft und dann mit dem passenden Empfänger über Pickup wieder weiter gesendet hat. Das System läuft wohl immer noch aber natürlich auf aktuelleren Versionen.

Für die Absicherung des SMTP-Servers gegen DoS und andere Attacken müssen Sie natürlich sorgen. Wenn ihr CRM aber primär Mails versendet und auch die Rückantworten automatisch klassifiziert werden, dann sind "fremde Mails" recht einfach zu erkennen. Ein "Offenes Relay" sollten sie aber nicht betreiben, denn die Existenz eines Mailservers auf Port 25/TCP bleibt nicht lange verborgen.

AntiSpam auf der anderen Seite

Wenn Sie ihre ausgehenden Mails zuverlässig beim Empfänger einliefern wollen, dann sollten Sie alle Register zur Prüfbarkeit ziehen. Denn auch die Empfänger arbeiten mit Spamfiltern. Der Versand über eine "vertrauenswürdige" IP-Adresse ist ebenso wichtig wie die Veröffentlichung dieser für ihre Domain zuständigen IP-Adressen per SPF. Aber auch die Signatur per DKIM und sogar eine Publizierung eine DMARC-Eintrags kann ihnen dabei helfen, die Zustellung zuverlässiger zu machen und sogar eine Rückmeldung bei Fehlern ihrerseits oder dem Versuch eines Spammers zu erhalten.

Wenn Sie für ihre "Massenmail" und die normale Bürokommunikation die gleichen Systeme nutzen, dann ist es um so wichtiger, dass Sie den Versand kontrollieren. Es gibt durchaus Gegenstellen, die ein "Volumen" ermitteln und so ein plötzliches Ansteigen der Anzahl versandter Mails als einen Indikator für Missbrauch oder offene Relays heranziehen. Das gilt insbesondere, wenn ihr CRM-System, warum auch immer, als Relay missbraucht werden kann. Es reicht vielleicht schon der Missbrauch als NDR-Backscatter.

Verschlüsselung

Leider ist der Einsatz von "Domain-Keys" für SMIME/PGP zwar möglich aber wird von den meisten Empfängern nicht verstanden oder nicht als ausreichend vertrauenswürdig angesehen. Wenn Sie nun für jeden Vorgang eine eigene Mailadresse generieren, dann ist eine Signatur per SMIME/PGP aktuell nicht wirklich sinnvoll. Sie können aber zumindest die Übertragung per SMTPTLS besser absichern. Wenn Sie z.B. den Versand zur per MX-Record ermittelten Gegenstelle per STARTTLS erzwingen, haben Sie für kompatible Gegenstellen schon etwas gewonnen.

Dazu gehört natürlich auch, dass Sie auf ihrer Seite ein passendes, gültiges und von einer vertrauenswürdigen CA ausgestelltes Zertifikat nachweisen.

Zusammenfassung

Der Betrieb einer ERP/CRM/Helpdesk/Newsletter-Lösung in Verbindung mit Exchange ist möglich. Allerdings rate ich davon ab, ein Exchange Postfach für diese Zwecke zu missbrauchen. Es kann allenfalls für einfachere Aufgaben eine Option ein, wenn der Betrieb einer "Shared Mailbox" für Support oder einfache Vertriebsaufgaben über eine automatisiert Nachverarbeitung erweitert werden soll. Sobald eine Umgebung aber etwas größer wird, mehr Mails versendet oder auch der Userpart eine Mailadresse zur Nachverfolgung und Zuordnung genutzt werden muss, führt eigentlich kein Weg an einer eigenen Domain oder Subdomain vorbei.

Weitere Links