nexus
Well-Known Member
Ich schätze deinen Enthusiasmus und die Tiefe, mit der du dieses Sicherheitsthema diskutierst – das ist absolut bereichernd für das Forum. Du lernst Neues, ich lerne Neues, perfekt.
Allerdings scheinst du dich in einer Entweder-oder-Logik festgefahren zu haben, die die Kompromisse des Massen-Hostings ignoriert.
1. Zwischen Ideal und Realität (Die "Ausrede" der SMTP-Spezifikation)
Du sagst, die SMTP-Spezifikation sei keine Ausrede, da Impersonation in 2025 "für alle" verhindert werden müsse.
Realität: Das ist eine moralische Forderung, keine ökonomische. Die technische Möglichkeit (Postfix-Prüfung) ist bekannt. Die Frage ist, warum Hoster diese zusätzliche Komplexität nicht in ihre günstigsten, automatisierten Basis-Produkte integrieren: weil es sich um ein Premium-Sicherheitsfeature handelt, das die Support- und Wartungskosten in die Höhe treibt, wenn es alte Workflows bricht.
Der Wettbewerbsvorteil, den du suchst, existiert bereits: Anbieter, die dieses Feature als Standard liefern, nennen es "Managed Mail" oder "Business Mail" und verlangen dafür entsprechend mehr. Das beweist, dass es kein unentgeltliches Basis-Feature ist, sondern ein Upgrade.
2. Der Knackpunkt Web-Applikationen (Wieso das Verbot nicht global geht)
Du suchst nach Anwendungen, die Impersonation benötigen, und zweifelst das Webmailer-Argument an. Hier liegt der Denkfehler in der Architektur von Shared Hosting:
Das Passwort-Argument: Das Übergeben des Passworts an den SMTP-Dienst bei jeder Mail ist nicht der Kernpunkt. Der Kern ist der Vertrauensmechanismus des Servers. Im Shared Hosting werden Mails oft intern über den lokalen MTA übergeben – dieser vertraut dem Webserver oder einem einzigen, technischen SMTP-Account.
Wenn du global verbietest: Du würdest nicht nur den Webmailer treffen. Du würdest jede tausendfach installierte, ältere oder schlecht konfigurierte Kundenanwendung (WordPress, Joomla, CRM, etc.) stoppen, die Mails über den lokalen MTA versendet, weil sie nur als ein einziger, technischer User authentifiziert ist, aber Mails im Namen von hunderten Endkunden verschicken muss.
Plesk/cPanel: Diese Systeme sind relevant, weil sie diese lokale Vertrauensarchitektur managen. Ein globales Verbot der Impersonation würde diese lokalen Mail-Workflows beeinträchtigen und damit die Funktionsfähigkeit vieler Webhosting-Pakete.
Fazit zur Architektonik: Ein Hoster kann keine Funktion global aktivieren, die potenziell 90 % der Kundenanwendungen ohne Vorwarnung lahmlegt, nur weil 10 % der Kunden eine höhere interne Sicherheit wünschen.
3. Zurück zur Ursache und Lösung
Ich bin einverstanden: Das Problem ist interessant und die Diskussion bereichernd. Aber:
Das Problem (Impersonation) ist bei Basis-Produkten systemisch angelegt (Preis vs. Feature-Set).
Die Lösung (Managed Hosting/Self-Hosting) wurde dir genannt.
Wenn du mit deinen hohen Sicherheitsanforderungen nicht in die Abo-Falle von Google/Microsoft treten willst, dann ist der Weg klar: Ein eigener, von dir konfigurierter Mailserver. Nur dort hast du die uneingeschränkte Kontrolle über die Postfix-Konfiguration, um dieses Feature zu aktivieren, ohne dich über die Geschäftsprinzipien von Massen-Hostern ärgern zu müssen.
Allerdings scheinst du dich in einer Entweder-oder-Logik festgefahren zu haben, die die Kompromisse des Massen-Hostings ignoriert.
1. Zwischen Ideal und Realität (Die "Ausrede" der SMTP-Spezifikation)
Du sagst, die SMTP-Spezifikation sei keine Ausrede, da Impersonation in 2025 "für alle" verhindert werden müsse.
Realität: Das ist eine moralische Forderung, keine ökonomische. Die technische Möglichkeit (Postfix-Prüfung) ist bekannt. Die Frage ist, warum Hoster diese zusätzliche Komplexität nicht in ihre günstigsten, automatisierten Basis-Produkte integrieren: weil es sich um ein Premium-Sicherheitsfeature handelt, das die Support- und Wartungskosten in die Höhe treibt, wenn es alte Workflows bricht.
Der Wettbewerbsvorteil, den du suchst, existiert bereits: Anbieter, die dieses Feature als Standard liefern, nennen es "Managed Mail" oder "Business Mail" und verlangen dafür entsprechend mehr. Das beweist, dass es kein unentgeltliches Basis-Feature ist, sondern ein Upgrade.
2. Der Knackpunkt Web-Applikationen (Wieso das Verbot nicht global geht)
Du suchst nach Anwendungen, die Impersonation benötigen, und zweifelst das Webmailer-Argument an. Hier liegt der Denkfehler in der Architektur von Shared Hosting:
Das Passwort-Argument: Das Übergeben des Passworts an den SMTP-Dienst bei jeder Mail ist nicht der Kernpunkt. Der Kern ist der Vertrauensmechanismus des Servers. Im Shared Hosting werden Mails oft intern über den lokalen MTA übergeben – dieser vertraut dem Webserver oder einem einzigen, technischen SMTP-Account.
Wenn du global verbietest: Du würdest nicht nur den Webmailer treffen. Du würdest jede tausendfach installierte, ältere oder schlecht konfigurierte Kundenanwendung (WordPress, Joomla, CRM, etc.) stoppen, die Mails über den lokalen MTA versendet, weil sie nur als ein einziger, technischer User authentifiziert ist, aber Mails im Namen von hunderten Endkunden verschicken muss.
Plesk/cPanel: Diese Systeme sind relevant, weil sie diese lokale Vertrauensarchitektur managen. Ein globales Verbot der Impersonation würde diese lokalen Mail-Workflows beeinträchtigen und damit die Funktionsfähigkeit vieler Webhosting-Pakete.
Fazit zur Architektonik: Ein Hoster kann keine Funktion global aktivieren, die potenziell 90 % der Kundenanwendungen ohne Vorwarnung lahmlegt, nur weil 10 % der Kunden eine höhere interne Sicherheit wünschen.
3. Zurück zur Ursache und Lösung
Ich bin einverstanden: Das Problem ist interessant und die Diskussion bereichernd. Aber:
Das Problem (Impersonation) ist bei Basis-Produkten systemisch angelegt (Preis vs. Feature-Set).
Die Lösung (Managed Hosting/Self-Hosting) wurde dir genannt.
Wenn du mit deinen hohen Sicherheitsanforderungen nicht in die Abo-Falle von Google/Microsoft treten willst, dann ist der Weg klar: Ein eigener, von dir konfigurierter Mailserver. Nur dort hast du die uneingeschränkte Kontrolle über die Postfix-Konfiguration, um dieses Feature zu aktivieren, ohne dich über die Geschäftsprinzipien von Massen-Hostern ärgern zu müssen.
