Mandantenmodus - Recipients belong to multiple Domains beim Versand an mehrere Mandanten

[Mueller]

Guten Nachmittag,

wir sind aktuell auf eine "interessante" Verhaltensweise des NoSpamProxys im Mandantenmodus gestoßen. Bei dem "Test" haben wir die Version 14.1 verwendet.

Das Problem macht sich wie folgt bemerkbar:

1. Ein Absender versendet eine E-Mail mit mindestens zwei Empfängeradressen, welche unterschiedlichen NoSpamProxy Mandanten zugehörig sind.
2. Beim "rcpt to:" zu dem 2. Mandanten erhält der Absender ein "452 4.5.3 Recipients belong to multiple domains."
   1. Wenn der Absender kein Mail-Quering unterstützt schlägt der Nachrichtenversand nun (teilweise) fehl.
3. Dieses Problem tritt sowohl beim Empfang als auch beim Versand auf. Beim Versand tritt das Problem auch auf, wenn dieselbe Regel und derselbe ausgehende Sende Konnektor verwendet wird.
4. Wie die folgende Einstellung gesetzt ist macht keinen Unterschied:
   1. 

Das Problem kann mittels telnet wie folgt nachgestellt werden:

220 mailout1.nospamproxy.de - Ready

ehlo test.de

250-mailout1.nospamproxy.de welcome

250-DSN

250-ENHANCEDSTATUSCODES

250-X-ANONYMOUSTLS

250-STARTTLS

250-8BITMIME

250 SIZE

mail from: <absender@mandant1.de>

250 2.0.0 Requested email action okay

rcpt to: <empfaenger1@mandant-1-oder-2-welcher-der-beiden-ist-egal.de>

250 2.0.0 Requested email action okay

rcpt to: <empfaenger2@mandant3.de>

452 4.5.3 Recipients belong to multiple domains.

DATA

T354 2.0.0 Start email input; end with <CRLF>.<CRLF>

Test

.

250 2.0.0 Queued email for delivery.

quit

Ob in der Empfängerliste noch mehrere andere Domains, welche nicht auf dem NoSpamProxy vorhanden sind existieren ist egal.


Das Absendende System ist mittels IP-Adresse zum Versenden berechtigt.



Gibt es eine Möglichkeit dieses Verhalten (Den Fehler "Recipients belong to multiple domains") zu unterbinden, wenn E-Mails über den NoSpamProxy versendet werden, da dieser Probleme mit Anwendungen ohne Mail-Quering produziert?



Danke

 

[Sören]

da diese Probleme mit Anwendungen ohne Mail-Quering produziert

Also ich bin da nicht im Thema, aber im Mandantenmodus kannst du doch die Mail Queue gar nicht deaktivieren, also sollte es maximal zu einer Verzögerung kommen....oder stehe ich auf dem Schlauch?

Dein Absendet ist doch auch kein "externer" sondern ein interner, weiterer Mandant...oder? Hast du es denn mal von mit einem externen Postfach probiert?

 

[StefanCink]

Hallo,
ich vermute, dass Mueller die einliefernde Software meint, die das Queueing nicht unterstützt. Das ist aus meiner Sicht allerdings ein absolutes NoGo, egal in welchem Szenario. Es kann jederzeit vorkommen, dass NSP oder jedes andere Gateway auch, gerade ein Problem hat und entweder gar nicht erreichbar ist, oder RFC-konform eine temporäre Fehlermeldung ausgibt. Da MUSS die einliefernde Software Queueing unterstützen, anderenfalls geht die E-Mail vermutlich verloren.
Gruß Stefan

 

[Mueller]

Hallo zusammen,
genau die einliefernde Software meine ich

ich vermute, dass Mueller die einliefernde Software meint, die das Queueing nicht unterstützt

Wenn die unsererseits betroffene Software ein SMTP Fehler bekommt, wird es 3x nochmal probiert. Jeder neue Versuch wird wieder mit der kompletten E-Mail (auch den bereits erfolgreich übermittelten Nachrichten) probiert, wodurch die Anwendung natürlich jedes mal auf denselben "Fehler" läuft. Wenn alle drei Versuche fehlgeschlagen sind gibt es ein Logeintrag zu dem fehlgeschlagenen Versand.

Natürlich ist dieses verhalten absolut nicht schön, allerdings leider bei vergleichsweise vielen Anwendungen "normal". (Wenn man dies überhaupt so nennen kann)

Da dieses Problem entweder durch ein zwischenstehendes System (z.B. Exchange oder Postfix) oder durch eine NoSpamProxy Konfigurationsanpassung gelöst werden muss, die Rückfrage.

Demnach möchte ich meine Frage hiermit einmal spezifizieren:
- Handelt es sich hierbei (beim Versand von Nachrichten über den NoSpamProxy) um ein gewolltes verhalten?
- Gibt es eine Möglichkeit z.B. durch eine Konfigzeile zu sagen, dass es beim Relaying über den NoSpamProxy (bei ausgehenden E-Mails) kein "452 4.5.3 Recipients belong to multiple domains" gibt? Diese Frage bezieht sich auf folgenden Bearbeitungszeitraum: Aufbau der SMTP Verbindung seitens der einliefernden Software bis Übergabe der E-Mail in die NoSpamProxy Mailquere.

Die Rückfragen dienen dazu die entsprechende Lösung für das Problem auszuwählen.

Falls die Lösung für das Problem mit NoSpamProxy umgesetzt werden könnte, würde der Mailfluss im Nachgang wie folgt aussehen: einliefernde Software -> NoSpamProxy Gatewayrolle (Mandant 1) -> DNS Auflösung für die Empfängerdomains -> NoSpamProxy Gatewayrolle (Mandant 2 und 3) -> Exchange der unterschiedlichen Empfänger.


Ich gehe aktuell davon aus, dass dieses Verhalten so gewünscht ist und es keinen Schalter zum Umstellen gibt, möchte dies allerdings gerne einmal kurz abklären, da es für viele Konfigurationsoptionen gefühlt keine (für Kunden zugängliche) Doku gibt.

Demnach wäre mir mit einem "geht wahrscheinlich" oder "geht wahrscheinlich nicht" schon sehr geholfen

Gruß
Mueller

 

[StefanCink]

Meines Wissens ist das Verhalten gewollt, da wir nur auf diese Art sicherstellen können, dass die jeweils richtige Regel ausgewählt wird. Es gibt zwar einen Schalter mit dem man das umschalten kann, ich weiß jedoch nicht, ob der auch im Multimandantenmodus so funktioniert. Ich vermute eher nicht.
Gruß Stefan

 

[JanJäschke]

Alle getroffenen Aussagen sind soweit korrekt.
Da du jedoch mit 14.1 getestet hast lass mich morgen bitte noch etwas prüfen, denn im Bereich „Recipients belong to multiple domains“ hatten wir nach der Einführung des Mandanten Modus etwas im Verhalten geändert. Dies wäre meiner Erinnerung nach entweder schon in 14.1 oder erst 14.2.
Aber da muss ich einmal nachschauen, kann auch sein das es dir gar nicht hilft. Aber sicher ist sicher ^^

LG
Jan

 

[JanJäschke]

Guten Morgen,

habe direkt einmal geschaut: die Änderung bezog sich nicht auf den Mandantenmodus. Also leider nicht hilfreich für dich
Hier bleibt also dann nur der Zwischenschritt über einen E-Mail Server um die E-Mails sauber verarbeiten zu lassen.


Gruß
Jan

 

[Mueller]

Guten Morgen,

danke für die schnelle Rückmeldung und Hilfe. Dann wählen wir den Weg mit dem zwischengeschalteten System.

 

[869288141]

Hallo zusammen,

danke für die schnelle Rückmeldung und Hilfe. Dann wählen wir den Weg mit dem zwischengeschalteten System.

löst aber nachhaltig dein Problem nicht. Weil auch hier kann es sein, dass der SMTP Service nicht funktionstüchtig ist. Aus meiner Sicht verlagerst du die Ursache nur von A nach B. Das Problem bleibt bestehen. Mir ist natürlich aus der Praxis bewusst, dass die Software Hersteller darauf keinen Schwerpunkt legen (wollen).

Wenn man es genau nimmt, führt kein Weg an zwei SMTP Relays vorbei. Am Besten noch mit einem Frontend Load Balancer. Denn in der Regel können die Anwendungen auch nicht mit MX Einträgen umgehen und lassen oftmals auch nur einen FQDN als E-Mail-Server zu. Somit ist bei Wartungsarbeiten oder Ausfällen das Risiko sehr gering, dass die E-Mail nicht zugestellt werden kann.

Es ist auf jeden Fall der teurere, aufwendige und fehleranfällige Weg. Aber technisch funktional.


Gruß,
Daniel

 

[DerGolo]

Feature Request

Ich bin auf das selbe Problem gestoßen. Für rein interne Mails, die zwischen den Mandanten fließen, lässt es sich mit Workarounds noch handhaben, wenn aber von extern eine Mail kommt, die an zwei unterschiedliche Mandanten geht, dann ist das ein echtes Problem, die Lösungsmöglichkeiten/Workarounds nicht praktikabel.

FRQ: Eine Möglichkeit, den Mandanten schon bei der Verbindungsannahme (SMTP TCP Session) zuzuordnen. Idee: Installation von dedizierten Gateways, die fix einem Mandanten zugeordnet sind. Oder, was noch schöner wäre: Die Möglichkeit, eigene Connectors zu erstellen, die dann auf anderen Ports (nicht 25) horchen und ebenfalls einen Mandanten fest zugeordnet werden können.

Was würde das bringen: Wenn ein Absender an zwei Mandanten in einer einzigen Mail schicken möchte, per DNS aber unterschiedliche MX findet, dann muss er die eine Mail schon von sich aus auf zwei getrennte aufteilen und damit ist das Problem umgangen. Wenn die Variante mit unterschiedlichen Ports gewählt wird, dann könnten diese nach außen über eine Firewall mit NAT und PAT veröffentlicht werden, so würde man sich separate VMs sparen.

@JanJäschke bei euch intern dokumentiert über Ticket von mir.

@Mueller würde das bei dir auch das PRoblem lösen?

Viele Grüße
Golo

 

[Mueller]

Hallo Golo,
ob der Feature-Request unser Thema lösen kann, hängt von der genauen Implementation ab.
Für deinen Fall (Eingehende Nachrichten aus dem Internet) muss ich gestehen, dass dies bei uns aktuell kein Thema ist.

Dies hängt damit zusammen, dass unsere Erfahrung (und den Standards nach) alle Systeme, welche über das Internet Versenden Mailquering unterstützen sollten.
Somit sind wir hier auf keine Probleme gestoßen.

Für deinen Sachverhalt möchte ich dir allerdings einen Gedankenanstoß mitgeben:

Könntest du auf deiner Gateway Rolle ein Zertifikat konfigurieren, welches für mehrere Subdomain gültig ist? (ggf. geht dies auch mit einen Wildcard Zertifikat)

Anschließend könntest du deine MX Einträge wie folgt aufteilen (zeigen alle auf dasselbe System):

- mx1a.domain.de

- mx1b.domain.de

- mb1c.domain.de

Theoretisch müsste das von dir gewünschte Verhalten anschließend schon erreicht werden.

 

[869288141]

Hallo Golo,

Die Möglichkeit, eigene Connectors zu erstellen, die dann auf anderen Ports (nicht 25) horchen und ebenfalls einen Mandanten fest zugeordnet werden können.

Per Definition ist für SMTP der Port 25/TCP vorgesehen. Entsprechend versucht der sendende Mailserver beim Verbindungsaufbau auch ausschließlich diesen Port anzusprechen.

Es gibt meines Wissens nach keine technische Möglichkeit, über DNS – weder per MX- noch per TXT-Record – dem gegenüberliegenden Mailserver einen alternativen Port für den SMTP-Verbindungsaufbau mitzuteilen. Der Port ist Bestandteil des Protokolls und nicht des DNS-Mechanismus.

Eigene Connectoren auf anderen Ports können daher nur in sehr kontrollierten Szenarien funktionieren (z. B. bei fest definierten Gegenstellen), sind aber keine allgemeingültige Lösung für den regulären E-Mail-Empfang aus dem Internet.

Wenn die Variante mit unterschiedlichen Ports gewählt wird, dann könnten diese nach außen über eine Firewall mit NAT und PAT veröffentlicht werden, so würde man sich separate VMs sparen.

Man sollte an der Stelle nicht nur von der eigenen, aktuell eingesetzten Plattform ausgehen, sondern auch über den Tellerrand schauen. Es gibt durchaus Kunden, die bewusst kein NAT/PAT einsetzen, sondern auf reines Routing setzen. Für diese fällt die genannte Variante damit grundsätzlich weg.

Unabhängig davon ist zu berücksichtigen, dass bei deinem Vorschlag meinem Verständnis nach zusätzliche öffentliche IPv4-Adressen erforderlich sind. Diese sind nicht immer im bestehenden Internet-Tarif enthalten und müssen im Zweifel kostenpflichtig beim ISP hinzugebucht werden. Sofern das überhaupt möglich ist.

Darüber hinaus sollte man das Thema auch im Kontext der Zukunftsfähigkeit betrachten: Wie würde ein solches Setup perspektivisch in einem Dual-Stack-Betrieb aussehen? IPv6 wurde nicht zuletzt genau deshalb entworfen, um die NAT-Krücke zu vermeiden. Ein Design, das weiterhin stark auf NAT/PAT setzt, läuft diesem Gedanken letztlich entgegen.


Gruß,
Daniel

 

[869288141]

Hallo Mueller,

Dies hängt damit zusammen, dass unsere Erfahrung (und den Standards nach) alle Systeme, welche über das Internet Versenden Mailquering unterstützen sollten.

Das ist in der Praxis leider nicht immer gegeben. Es gibt durchaus WebApplikationen, die zwar eine Mail-Queue besitzen, jedoch keinen automatischen erneuten Versand bei Fehlern unterstützen.

Darüber hinaus existieren auch WebApps, die überhaupt keine Queue implementiert haben – in diesen Fällen sind E-Mails bei einem Zustellfehler schlicht verloren.

Gerade bei kritischen Anwendungen versucht man dieses Risiko häufig durch vorgelagerte SMTP-Relays, idealerweise redundant ausgelegt (z. B. im Cluster oder hinter einem Load Balancer), zu minimieren. Damit lässt sich zumindest sicherstellen, dass die Anwendung selbst nicht für das Retry-Handling verantwortlich ist.

Könntest du auf deiner Gateway Rolle ein Zertifikat konfigurieren, welches für mehrere Subdomain gültig ist? (ggf. geht dies auch mit einen Wildcard Zertifikat)

Grundsätzlich ist es möglich, ein Zertifikat für mehrere Subdomains zu verwenden. Aus Security-Sicht sollte man jedoch, wann immer möglich, auf Wildcard-Zertifikate verzichten und stattdessen die benötigten FQDNs explizit über Subject Alternative Names (SANs) abbilden.

Der Hintergrund ist das Risiko: Gerät ein Wildcard-Zertifikat in falsche Hände, betrifft der Schaden nicht nur einen einzelnen Dienst, sondern potentiell alle Subdomains. In diesem Fall wird das Zertifikat faktisch zu einem Freifahrtschein für einen Angreifer.

SAN-Zertifikate begrenzen den Impact deutlich, da sie nur für die konkret benannten Hostnamen gültig sind und sich somit besser in ein Least-Privilege- und Defense-in-Depth-Konzept einfügen.

Anschließend könntest du deine MX Einträge wie folgt aufteilen (zeigen alle auf dasselbe System):

- mx1a.domain.de

- mx1b.domain.de

- mb1c.domain.de

Das Konstrukt verstehe ich noch nicht ganz. Bisher gibt es ja nur einen MX-Eintrag. Nennen wir ihn mx1.domain.de, der auf den Server mit der NoSpamProxy-Gateway-Rolle zeigt.

Könntest du erläutern, welchen Vorteil deine vorgeschlagene Aufteilung auf mx1a.domain.de, mx1b.domain.de, mx1c.domain.de bringen soll? Vielleicht magst du den Vorschlag noch etwas ausführlicher erklären.


Gruß,
Daniel

 

[DerGolo]

@Daniel: Danke für deine Ideen - ich stimme in allen Punkten zu.

@Mueller: Die Idee klingt verlockend, hat aber einen kleinen Haken, denke ich: Der NSP meldet sich bei einem eingehenden Verbindungsaufbau ja immer mit nur einem einzigen Hostnamen, also dem SMTP Banner. Einige Mailserver prüfen ab, ob die SMTP Banner zum MX und zum Zertifikat passt. Wenn also nun z.B. 3 Mandanten verwendet werden und alle eigene MX Hostnamen bekommen, dann müsste ich auch für jeden Mandanten eine eigene Gateway-Rolle bereitstellen, denn nur so kann ich die SMTP Banner individuell zuordnen. Bei Redundanz wären das dann schon 6 Instanzen. Das widerspräche auch dem Shared-Ressources Gedanken in einer Multi-Mandanten Umgebung. Zugegebenermaßen ist das bei meinem FRQ aber auch schon der Fall. Und wie bei dir auch, ist der Fall konstruiert, tatsächlich tauchen die Probleme derzeit nur intern auf (wie von Daniel beschrieben), noch nicht aus dem Internet, da werde ich noch einmal etwas nachforschen und testen.