Mail-Hoster, wo nicht jeder die Absender-Adresse verfälschen kann

[rdiez]

Hallo alle:

Beim Hetzner "Level 9" Hosting-Produkt und Ähnlichen erstellt man zwar getrennte E-Mail-Postfächer mit unterschiedlichen SMTP-Passwörtern, aber jeder [email protected] kann sich beim Versenden von E-Mails als [email protected] ausgeben.

Das betrifft sowohl die Envelope-Absenderadresse (SMTP "MAIL FROM") als auch den "From:" Mail-Header. Die einzige Voraussetzung ist, dass die verfälschte E-Mail-Adresse [email protected] existiert, egal bei welchem Postfach.

Eine ähnliche Erfahrung habe ich mit DomainFactory gemacht, bevor diese Firma vor Kurzem auf Microsoft Outlook 365 gewechselt hat. Das hatte mir damals der Support bestätigt.

Netcup hat das gleiche Problem (zumindest das kleinste Webhosting Produkt). Es ist also anscheinend ein verbreitetes Problem.

Ich habe versucht, das Thema im Hetzner-Forum anzusprechen, aber diese Impersonation wird als normal angesehen ("so funktioniert halt SMTP"), und der Ton wird schnell rau. Dieses Forum ist nur für Kunden gedacht, und nicht öffentlich.

Aus vielen Gründen wollte ich bei einem Standard-E-Mail-Provider bleiben, und nicht in die übliche Abo-Falle von Microsoft, Google und Co. eintreten.

Kennt jemand hier vielleicht einen "normalen" Web/Mail-Hoster ohne diese Macke? Hoffentlich in Deutschland, oder zumindest in der EU.

Diese Impersonation-Lücke ist bislang das Einzige, das mich an solchen "einfachen" E-Mail-Hosting-Angeboten stört. Fehlende Kalender und andere Gruppenfunktionen war für mich noch kein großes Problem.

Danke im Voraus,
rdiez

 

[Thorsten]

Ich habe versucht, das Thema im Hetzner-Forum anzusprechen, aber diese Impersonation wird als normal angesehen ("so funktioniert halt SMTP"), und der Ton wird schnell rau. Dieses Forum ist nur für Kunden gedacht, und nicht öffentlich.

Da braucht der Ton nicht rau werden, aber so funktioniert SMTP halt. Dich kann ja auch niemand davon abhalten, Donald Duck aus Entenhausen auf einen Briefumschlag zu schreiben und diesen in einen Briefkasten zu werfen.

 

[rdiez]

[...] aber so funktioniert SMTP halt. [...]

SMTP-Server können aber eine solche Verfälschung unterbinden. Im Falle von Postfix, die Dokumentation für smtpd_sender_login_maps erklärt:

By default an SMTP client may specify any envelope sender address in the MAIL FROM command. That is because the Postfix SMTP server only knows the remote SMTP client hostname and IP address, but not the user who controls the remote SMTP client.

This changes the moment an SMTP client uses SASL authentication. Now, the Postfix SMTP server knows who the sender is. Given a table of envelope sender addresses and SASL login names, the Postfix SMTP server can decide if the SASL authenticated client is allowed to use a particular envelope sender address.

 

[dataforest]

Ich hatte den Hetzner-Thread auch gelesen und mir das direkt fürs nächste Weekly aufgeschrieben, da ich diese Restriktion bei unserem Webhosting gerne aktivieren lassen würde, wenn aus Sicht der Kollegen ebenfalls nichts dagegenspricht. Vielleicht ist das auch schon so. Ich werde gerne berichten

VG
Tim

 

[Thorsten]

Restriktion oder Erweiterung oder Extra Konfiguration ist hier dann aber auch das richtige Stichwort. SMTP sieht hier eine solche Prüfung grundsätzlich nicht vor.

 

[rdiez]

Ich hatte den Hetzner-Thread auch gelesen und mir das direkt fürs nächste Weekly aufgeschrieben, da ich diese Restriktion bei unserem Webhosting gerne aktivieren lassen würde, wenn aus Sicht der Kollegen ebenfalls nichts dagegenspricht. Vielleicht ist das auch schon so. Ich werde gerne berichten

Zur Info: Ich habe bei Postfix gefragt, und der Maintainer hat mir erklärt, wie man es genau macht, wenn man diese Prüfung nicht bei allen SMTP-Konten machen möchte:

[pfx] Re: reject_sender_login_mismatch only for some SMTP accounts
Thu, 18 Sep 2025 09:00:50 -0700

https://www.mail-archive.com/[email protected]/msg106479.html

Ich finde aber, eine solche Ausnahme sollte man in der Regel nicht machen.

 

[nexus]

ohne diese Macke

It's not a Bug, it's a Feature

Nein im Ernst...Du verkennst hier möglicherweise die Geschäftsprinzipien eines solchen Mailhosters. Alle Produktlinien (bis auf die Managed Geschichten) sollen nach Möglichkeit vollautomatisiert, also möglichst ohne personellen Aufwand laufen.
Wenn jetzt Kunden mit Extrawünschen kommen, müßte der Hoster Manpower dafür einsetzen, was ihn wiederum Geld kostet.

Wenn du etwas individuelles möchtest, hast du IMHO zwei Möglichkeiten:
- Du mietest dir einen Mailserver mit managed Option an...dann wird der Anbieter alle deine individuellen Wünsche umsetzen
- Du setzt dir selber einen Mailserver auf...den kannst du dir dann nach Herzenslust konfigurieren

 

[dataforest]

Wir würden das wenn dann global setzen und nicht individuell konfigurierbar machen. Ich will den Glaubenskrieg im Hetzner-Forum nicht ins SSF rübertragen, bin aber der Meinung, dass die "Fälschbarkeit" des Absenders zwar in der Tat kein Fehlverhalten bzw. keine Fehlkonfiguration darstellt, der Wunsch aus Kundensicht jedoch nachvollziehbar ist, um ein bisschen (vermeintliche? ) Sicherheit zu gewinnen, und vermutlich wenig dagegenspricht, diese Restriktion umzusetzen. Ein bisschen schützen wir uns mit einer solchen Einstellung dann vielleicht auch selbst, denn automatisierter Missbrauch gehackter Mailkonten wird tendenziell etwas nutzloser. Die Bots prüfen wahrscheinlich nicht, ob ihre Absenderfälschung funktioniert, und failovern bei einem Nein auf die Verwendung des SMTP-Loginnamens. Viel macht das aber auch nicht aus, weil wir ordentlich ratelimiten und Mailqueues sowie Blacklistings 24/7/365 monitoren und an die Bereitschaft alerten.

Und unter uns, da ich hier ja auch ganz gerne aus dem Nähkästchen plaudere: Webhosting (im Sinne von Webspace) macht nur noch etwa 2% unseres Umsatzes aus. Das wird insofern eine Ja-Nein-Entscheidung in fünf Minuten werden. Individuelle Anpassungen je SMTP-Konto können wir so oder so nicht abbilden, weder in die eine noch in die andere Richtung. Aber wenn ich etwas aufschnappe, was ich (potenziell) für sinnvoll halte, nehme ich das gerne mit.

VG
Tim

 

[dataforest]

- Du mietest dir einen Mailserver mit managed Option an...dann wird der Anbieter alle deine individuellen Wünsche umsetzen

Das geht natürlich auch, wir betreiben inzwischen für viele Kunden managed Mailcows. Ist eine sehr gute Lösung und da geht quasi alles – auch das, was hier gefordert ist.

 

[nexus]

Wir würden das wenn dann global setzen

Kannst du auch nicht so einfach...es gibt durchaus bestimmte Workflows die das nutzen, z.B. wenn eine Applikation E-Mails im Namen verschiedener Nutzer versendet...
Wenn du das global deaktivierst, bekommt der Support einiges zu tun

 

[dataforest]

Deshalb bespreche ich das mit den zuständigen Kollegen und rolle es nicht eben selbst aus

Ich weiß nicht. Meine persönliche Vermutung ist, dass solche Applikationen eher PHP mail() nutzen und davon nicht betroffen wären. Bei "normalen" Mailclients sollte sich der Pain in Grenzen halten. Und wenn dem nicht so sein sollte, ist sowas ja auch reversibel. Vermutlich würden wir es darüber hinaus auch erstmal auf der Statusseite ankündigen.

 

[rdiez]

It's not a Bug, it's a Feature

Nein im Ernst...Du verkennst hier möglicherweise die Geschäftsprinzipien eines solchen Mailhosters. Alle Produktlinien (bis auf die Managed Geschichten) sollen nach Möglichkeit vollautomatisiert, also möglichst ohne personellen Aufwand laufen.
Wenn jetzt Kunden mit Extrawünschen kommen, müßte der Hoster Manpower dafür einsetzen, was ihn wiederum Geld kostet.

Ich denke, Schutz gegen Fälschung / Impersonation sollte eigentlich zur Basis gehören.

Impersonation ist für meine Nutzer riskant und die Folgen reichen von peinlich bis wirtschaftliche Schäden.

Ein solcher Schutz lässt sich sowieso komplett automatisieren, auch wenn man eine solche Option anbieten würde:

[x] Dieser Benutzer darf E-Mails nur mit folgenden Absenderadressen versenden: [ [email protected], [email protected] ]

Eine solche sichtbare Option würde wohl die Anzahl an zusätzlichen Support-Calls minimieren.

Die Automatisierung mag schwierig oder unwirtschaftlich für einige Hosters sein, je nach SMTP-Server und Umstände. Es wäre aber wohl ein Wettbewerbsvorteil, wenn Einer das macht, und als seine Stärke ausweist.

 

[nexus]

Die Automatisierung mag schwierig oder unwirtschaftlich für einige Hosters sein, je nach SMTP-Server und Umstände. Es wäre aber wohl ein Wettbewerbsvorteil, wenn Einer das macht, und als seine Stärke ausweist.

Es gibt durchaus Anbieter, die sowas machen...Nur sind das eben nicht die Bigplayer am Markt.
Wenn du den Thread aufmerksam gelesen hast, hat sich schon ein Anbieter geoutet, der sowas anbietet:

wir betreiben inzwischen für viele Kunden managed Mailcows

 

[rdiez]

Kannst du auch nicht so einfach...es gibt durchaus bestimmte Workflows die das nutzen, z.B. wenn eine Applikation E-Mails im Namen verschiedener Nutzer versendet...

Es würde mich interessieren, welche Applikationen die Identität aller Benutzer wirklich imitieren müssen, und wofür genau.

Das Haupt-Problem bei solchen Applikationen ist dann: wenn jemandem gelingt, in die Applikation einzubrechen, kann er auch die Identität jedes Benutzers per E-Mail imitieren. Aus Sicherheitsgründen sollte man eigentlich immer versuchen, die Bereiche zu trennen und die Rechte zu beschränken, damit so etwas nicht möglich ist.

Ob unterschiedliche "Reply-To:" Mail-Header nicht ausreichen?

Es gibt übrigens Leute, die behaupten, E-Mails sollten sowieso mit individuellen PGP oder S/MIME verschickt werden. Vermutlich hätten solche Applikationen dann Schwierigkeiten, weil sie dann alle Signierungsschlüssel aller Benutzer kennen müssten.

 

[Thorsten]

Bei den konkreten Anforderungen die du hast, in Verbindung mit einem doch scheinbar vorhandenen Hintergrundwissen: Warum betreibst du nicht einen eigenen Mailserver mit exakt diesen Anforderungen @rdiez?

 

[danton]

Es würde mich interessieren, welche Applikationen die Identität aller Benutzer wirklich imitieren müssen, und wofür genau.

Mir fallen da spontan Webmailer sein. Die Authentifizierung erfolgt per Browser und Webserver und der wird dann auch beim Mailversand vertraut, d.h. es erfolgt nicht zwingend eine SASL-Anmeldung per SMTP. Das macht auch sicherheitstechnisch Sinn, denn sonst müsste man das Passwort der Browser-Anmeldung ja irgendwo auf dem Server zwischenspeichern oder bei jeder gesendeten Mail erneut eingeben.

 

[dataforest]

Guter Punkt. Vielleicht das K.O.-Kriterium das ich nicht auf dem Schirm hatte. Ich melde mich am Mittwoch

 

[rdiez]

Mir fallen da spontan Webmailer sein. Die Authentifizierung erfolgt per Browser und Webserver und der wird dann auch beim Mailversand vertraut, d.h. es erfolgt nicht zwingend eine SASL-Anmeldung per SMTP. Das macht auch sicherheitstechnisch Sinn, denn sonst müsste man das Passwort der Browser-Anmeldung ja irgendwo auf dem Server zwischenspeichern oder bei jeder gesendeten Mail erneut eingeben.

Ich vermute mal, die meisten Webmailer verwenden das normale SMTP. Das Passwort bei der Browser-Anmeldung wird wohl einfach im Speicher gehalten, solange die Webmailer-Session bleibt.

RoundCube:

Configuration

The Roundcube Webmail suite. Contribute to roundcube/roundcubemail development by creating an account on GitHub.

github.com

"For sending emails, Roundcube uses the SMTP protocol to submit a composed message via the "outgoing mail server". Similar to the IMAP connection, configuring the SMTP server is part of a minimal Roundcube setup."

Horde:

webmail/doc/INSTALL.rst at master · horde/webmail

Horde Groupware Webmail Edition. Contribute to horde/webmail development by creating an account on GitHub.

github.com

"Horde Groupware Webmail Edition sends mail via either a local sendmail or aremote SMTP server. It is RECOMMENDED that SMTP be used."

Im Fall von Horde, wenn man "local sendmail" verwendet, dann werden die SMTP-Regeln bei Postfix etc. nicht angewendet, daher hätte eine Verschärfung der SMTP-Prüfungen keine Wirkung da. Das Problem dabei wäre, dass ein Hacker, der die Webmail-Anwendung kapert, Impersonation ohne Ende machen kann. Das ist wohl der Grund, warum Horde SMTP empfiehlt. Dadurch wären nur diejenigen Benutzer betroffen, deren Passwörter der Hacker stiehlt.

Ich würde noch gerne wissen, unter welchen Umständen irgendeine Software tatsächlich eine solche E-Mail-Impersonation braucht. Im Moment vermute ich, dass es generell keine gute Idee ist, und die Software, die das verlangt, einfach schlecht geschrieben ist. Das hatten wir nämlich schon mal: In der Vergangenheit wollten viele Mailing-List-Servers E-Mails senden im Namen der List-Mitglieder, bis zu viel Missbrauch den Aufstieg von SPF und Co. brachte, und dann mussten alle Mailing Lists umstellen. Viele Mailing-List-Admins haben sich damals dagegen gewehrt, auch mit komischen Argumenten, aber das hat alles nichts genutzt, und heutzutage ist SPF/DMARC einfach ein Muss, gerade um Impersonation vorzubeugen.

 

[nexus]

In der Vergangenheit wollten viele Mailing-List-Servers E-Mails senden im Namen der List-Mitglieder, bis zu viel Missbrauch den Aufstieg von SPF und Co. brachte, und dann mussten alle Mailing Lists umstellen. Viele Mailing-List-Admins haben sich damals dagegen gewehrt, auch mit komischen Argumenten, aber das hat alles nichts genutzt, und heutzutage ist SPF/DMARC einfach ein Muss, gerade um Impersonation vorzubeugen.

Sorry, aber jetzt vergleichst du Äpfel mit Birnen.
DMARC/SPF verhindern das Fälschen der Absenderadresse von außen (wenn die Mail zu einem anderen Mailserver geschickt wird). Das Problem im Thread betrifft jedoch die Authentifizierung von innen – also zwischen dem Kunden und dem eigenen Server. Es ist ein lokales Sicherheitsfeature, das über den SMTP-Standard hinausgeht, und wird daher von Basis-Hosting-Produkten oft nicht als Standard-Feature angeboten.

Ich würde noch gerne wissen, unter welchen Umständen irgendeine Software tatsächlich eine solche E-Mail-Impersonation braucht.

Nicht jede Anwendung, die E-Mails verschickt (z.B. ein altes CRM, ein Forum, oder eine Ticket-Software), ist in der Lage, sich für jeden Benutzer separat per SASL am SMTP-Server zu authentifizieren. Oftmals authentifizieren sich diese Anwendungen nur einmal als ein technischer Benutzer ([email protected]) und senden Mails im Namen anderer. Dies ist eine eingebürgerte Architektur, die für Hoster mit tausenden Kunden schwer global zu ändern ist.
Zu deiner Skespis beim Thema Webmailer...
Der Webmailer-Einwand ist valide. Wenn der Webserver selbst als vertrauenswürdig gilt, kann er Mails für jeden Nutzer versenden, ohne dass jeder Nutzer sein Passwort erneut an den SMTP-Dienst übergeben muss. Wenn man hier die Impersonation global verbietet, könnte es die Funktionalität vieler Webhosting-Plattformen (Plesk, cPanel) beeinträchtigen, die darauf aufbauen, dass der lokale Mail-Transport (oder der technische Account) vertrauenswürdig ist.


Meine bescheidene Meinung zum Thread:
Die Diskussion über die Mängel des SMTP-Standards oder die "schlechte Programmierung" von Software ist ein interessantes akademisches Thema, löst aber nicht das akute Problem.
Du hast dich argumentativ von deiner ursprünglichen Intention, einen Anbieter zu finden, der dir die gewünschten Restriktionen anbietet, sehr weit entfernt. Ich habe das Gefühl, du möchtest dieses spezielle Problem am liebsten für alle aus der Welt schaffen...wird nur leider nicht funktionieren.
Die Lösungen für dein Problem wurden bereits genannt (managed Hosting / Self Hosting). Prüfe, ob das Optionen für dich sind.

 

[rdiez]

Es ist ein lokales Sicherheitsfeature, das über den SMTP-Standard hinausgeht, und wird daher von Basis-Hosting-Produkten oft nicht als Standard-Feature angeboten.

Es wird tatsächlich oft behauptet, dass ein solches Feature über den SMTP-Standard hinausgeht. Ich verstehe aber die Argumentation nicht. Es gibt im SMTP-Standard nichts, das besagt, der STMP-Server sollte gefälschte Absender-Adresse hinnehmen. Selbst, wenn das so wäre, können alle SMTP-Server das seit Langem vermeiden. Und in 2025 muss man halt Impersonation verhindern, egal auf welcher Ebene. Als Ausrede taugt die SMTP-Spezifikation also nicht wirklich.

und wird daher von Basis-Hosting-Produkten oft nicht als Standard-Feature angeboten.

Sorry, aber in 2025 ist das keine Ausrede mehr. Alle müssen Impersonation verhindern, egal wie günstig. Diejenigen, die das nicht schaffen, gehören dann an den Pranger, besonders wenn diese Anbieter das Problem verschleiern (oder "vergessen" zu erwähnen).

Nicht jede Anwendung, die E-Mails verschickt (z.B. ein altes CRM, ein Forum, oder eine Ticket-Software), ist in der Lage, sich für jeden Benutzer separat per SASL am SMTP-Server zu authentifizieren. Oftmals authentifizieren sich diese Anwendungen nur einmal als ein technischer Benutzer ([email protected]) und senden Mails im Namen anderer. Dies ist eine eingebürgerte Architektur, die für Hoster mit tausenden Kunden schwer global zu ändern ist.

Ich verwende täglich Forums, Mailing-Listen, Bug-Trackers und andere Groupware-Systeme, und keine davon muss E-Mails in meinem Namen versenden. Die Benachrichtigungs-E-Mails kommen alle erkennbar von der Software, die sie versendet. Das ist der Grund, warum ich gerne wissen möchte, welche Systeme eine E-Mail-Impersonation wirklich brauchen.

Der Webmailer-Einwand ist valide. Wenn der Webserver selbst als vertrauenswürdig gilt, kann er Mails für jeden Nutzer versenden, ohne dass jeder Nutzer sein Passwort erneut an den SMTP-Dienst übergeben muss.

Ist es nicht. Wie schon erwähnt, man tippt sein Passwort bei der Anmeldung beim Webmailer ein. Da kann der Webmailer das Passwort im Speicher halten und beim Versand über SMTP übergeben. Das ist wohl, wie die meisten Webmailer arbeiten. Ansonsten würde ich gerne Bescheid wissen, einfach aus Neugier.

Es ist schon passiert, dass ein Hacker in ein Webmailer oder Webserver einbricht. Daher würde ich sowieso versuchen, die Bereiche gut zu trennen, damit der Webserver nicht einfach alle impersonieren kann, z.B. auch [email protected], der keinen Webmailer verwenden dürfte.

Wenn man hier die Impersonation global verbietet, könnte es die Funktionalität vieler Webhosting-Plattformen (Plesk, cPanel) beeinträchtigen, die darauf aufbauen, dass der lokale Mail-Transport (oder der technische Account) vertrauenswürdig ist.

Plesk, cPanel etc. arbeiten auf einer anderen Ebene. Sie verarbeiten nämlich direkt die Konfigurationsdateien auf dem Server und senden selbst keine E-Mails über SMTP. Solche Systeme sind immer noch kein Grund, um SMTP-Impersonation für andere Systeme wie Webmailer zu ermöglichen.

Und auch wenn SMTP-Impersonation sein müsste, man sollte es wie gesagt auf dem einem oder anderen SMTP-Konto ermöglichen, aber halt nicht für alle.

Du hast dich argumentativ von deiner ursprünglichen Intention, einen Anbieter zu finden, der dir die gewünschten Restriktionen anbietet, sehr weit entfernt.

Ich möchte immer noch einen solchen Anbieter finden. Und ja, es wäre schön, dieses Problem für alle aus der Welt zu schaffen. Und ja, es gibt interessante Askepte darum herum, die ich gerne bespreche. Und ja, ich möchte auch die möglichen Einwände und Ausreden wiederlegen. Dadurch lerne ich mal etwas Neues. Es ist nämlich schon passiert, dass ich eines Besseren gelehrt wurde. Ist auch nicht schlimm.

Ich dachte, ein solcher, vielfältiger Austausch ist für ein Forum wie dieses in Ordnung. Ob ich "mein" Problem löse ist dabei nicht so wichtig. Ich lebe nämlich mit vielen ungelösten Probleme.