E-Mails von fremder Domain versenden

[paedubucher]

Ich betreibe einen E-Mail-Server für meinen Arbeitgeber (Postfix). Damit handhaben wir die E-Mails von unserer Domain, nennen wir sie mal arbeitgeber.com. Nun hat ein Kunde eine Anwendung bei uns gehostet, die unter anwendung.kunde.com bei uns gehostet ist. Die Domain unseres Kunden, kunde.com, ist jedoch nicht bei uns gehostet. Der DNS-Server des Kunden ist aber so konfiguriert, dass anwendung.kunde.com auf unseren Server zeigt. Soweit so gut.

Nun soll diese Anwendung auch E-Mails an die Benutzer verschicken. Meine naheliegende Idee wäre es, dass der Kunde einen entsprechenden MX-Record für anwendung.kunde.com einrichtet, der dann auf unseren E-Mail-Server zeigt. Ein entsprechender SPF-Record wäre ebenfalls sinnvoll. So könnten wir auf unserem Postfix einen Benutzer info@anwendung.kunde.com einrichten, und von dem aus die E-Mails versenden. Und das wäre auch meine erste Frage: Wäre dieses Vorgehen grundsätzlich sinnvoll?

Der Kunde hat jedoch einen nicht technischen Grund genannt, warum die Mails nicht von anwendung.kunde.com sondern direkt von kunde.com versendet werden sollten. Ich paraphrasiere den Grund mal als "das haben wir sonst auch immer so gemacht". Ich sehe hier zwei Möglichkeiten:

• Ich konfiguriere die Domäne kunde.com auf unserem Postfix-Server. So kann ich mit einem entsprechenden Benutzer info@kunde.com E-Mails versenden. Das Problem ist jedoch, dass ausgehende E-Mail-Kommunikation, die nicht über die Kundenanwendung geht, auf dem Mailserver Probleme macht. Der Server glaubt dann, er müsse Adressen wie otto.normalverbraucher@kunde.com auf unserem eigenen Server auflösen. Vielleicht gibt es hier eine Möglichkeit, Postfix so zu konfigurieren, dass er andere Adressen als info@anwendung.com nicht aufzulösen versucht. (Ich bin mit Postfix leider nicht so versiert. Die Frage ist auch eher, ob der Ansatz grundsätzlich sinnvoll wäre.)

• Ich konfiguriere keine weitere Domäne auf unserem Postfix-Server, sondern bloss die Adresse kunde@arbeitgeber.com, von der aus dann die Applikation E-Mails verschickt. Als eigentlicher Benutzer wird dann die besagte Adresse verwendet, der Sender-Header wird aber als info@kunde.com angegeben. Das geht ja mit SMTP technisch problemlos. Die Frage ist aber hier, ob ich dadurch vielleicht die Reputation unseres E-Mail-Servers schädigen könnte, was ich natürlich nicht will. Genügt hier ein entsprechender SPF-Record aufseiten des Kunden, um dies zu verhindern?

Grundsätzlich bevorzuge ich ja die konsistente Variante mit der Subdomain für Anwendung und Mailversand. Aber ich bin ja nur der dumme Techniker... Von E-Mail habe ich ja offenbar wirklich keine Ahnung

[Meillo]

Ich betreibe einen E-Mail-Server für meinen Arbeitgeber (Postfix). Damit handhaben wir die E-Mails von unserer Domain, nennen wir sie mal arbeitgeber.com. Nun hat ein Kunde eine Anwendung bei uns gehostet, die unter anwendung.kunde.com bei uns gehostet ist. Die Domain unseres Kunden, kunde.com, ist jedoch nicht bei uns gehostet. Der DNS-Server des Kunden ist aber so konfiguriert, dass anwendung.kunde.com auf unseren Server zeigt. Soweit so gut.

Nun soll diese Anwendung auch E-Mails an die Benutzer verschicken. Meine naheliegende Idee wäre es, dass der Kunde einen entsprechenden MX-Record für anwendung.kunde.com einrichtet, der dann auf unseren E-Mail-Server zeigt. Ein entsprechender SPF-Record wäre ebenfalls sinnvoll. So könnten wir auf unserem Postfix einen Benutzer info@anwendung.kunde.com einrichten, und von dem aus die E-Mails versenden. Und das wäre auch meine erste Frage: Wäre dieses Vorgehen grundsätzlich sinnvoll?

IMO ja.

Der Kunde hat jedoch einen nicht technischen Grund genannt, warum die Mails nicht von anwendung.kunde.com sondern direkt von kunde.com versendet werden sollten. Ich paraphrasiere den Grund mal als "das haben wir sonst auch immer so gemacht". Ich sehe hier zwei Möglichkeiten:

Das effektivste Argument in diesen Faellen ist (leider!) zumeist: Das geht (technisch) nicht anders!

• Ich konfiguriere die Domäne kunde.com auf unserem Postfix-Server. So kann ich mit einem entsprechenden Benutzer info@kunde.com E-Mails versenden. Das Problem ist jedoch, dass ausgehende E-Mail-Kommunikation, die nicht über die Kundenanwendung geht, auf dem Mailserver Probleme macht. Der Server glaubt dann, er müsse Adressen wie otto.normalverbraucher@kunde.com auf unserem eigenen Server auflösen. Vielleicht gibt es hier eine Möglichkeit, Postfix so zu konfigurieren, dass er andere Adressen als info@anwendung.com nicht aufzulösen versucht. (Ich bin mit Postfix leider nicht so versiert. Die Frage ist auch eher, ob der Ansatz grundsätzlich sinnvoll wäre.)

Den Mailserver den du im MX-Record angibst muss die Mails fuer die Domain verwalten koennen. AFAIK geht es nicht, dass du zwei Mailserver hast, die jeweils nur eine Teilmenge der Adressen verwalten kann, naemlich info@ bei dir und alles andere beim Kunde.

• Ich konfiguriere keine weitere Domäne auf unserem Postfix-Server, sondern bloss die Adresse kunde@arbeitgeber.com, von der aus dann die Applikation E-Mails verschickt. Als eigentlicher Benutzer wird dann die besagte Adresse verwendet, der Sender-Header wird aber als info@kunde.com angegeben. Das geht ja mit SMTP technisch problemlos. Die Frage ist aber hier, ob ich dadurch vielleicht die Reputation unseres E-Mail-Servers schädigen könnte, was ich natürlich nicht will. Genügt hier ein entsprechender SPF-Record aufseiten des Kunden, um dies zu verhindern?

Laut RFC ist Sender der technische Absender, in dem Fall also <info@anwendung.kunde.com>. From ist der inhaltliche Absender, also <info@kunde.com>. (Dann kann man noch Reply-To setzen.)

Das Problem ist, dass AFAIK DMARC Sender-Header schlichtweg ignoriert, weshalb die ganzen Mailinglisten kaputt gehen. Sobald die From-Adresse nicht von dem Server ist, auf den der MX-Record zeigt, hast du ein Problem als Spam klassifiziert zu werden. (Dieser Umgang mit From und Sender widerspricht den RFCs, nach denen From z.B. auch mehrere Personen/Adressen sein koennen, dann muss es aber einen Sender geben, der immer nur genau eine Adresse enthaelt. Das aber nur nebenbei.)


Meine Empfehlung waere, dem Kunden klarzumachen, dass nur dein obiger Vorschlag moeglich ist, weil das andere entweder technisch nicht geht oder die Mails als Spam klassifiziert werden. (Falls es ihm dennoch so wichtig waere, sollte er gehoerig Kohle rueberwachsen lassen, dann kann man sich die Umwege mit all ihren Nachteilen nochmal ueberlegen. Empfehlen wuerde ich sie nicht; die werden nur Probleme erzeugen, Fehlerquellen generieren, instabil sein.)


Weitere (auch gegensaetzliche) Meinungen willkommen!

[heisenberg]

Das alle Mails eines Unternehmens auch von seiner Domain kommen, finde ich sehr sinnvoll.

Z. B. deswegen, dass der Kunde mit seiner Stammdomain als solcher wahrgenommen wird.

Der einfachste Weg, der mir da einfällt, wäre der, dass der Kunde einen SMTP-Account bereitstellt, mit dem sich dein Server am Kundenmailserver authentifiziert und mit dem die Mails über selbigen verschickt.

[heisenberg]

Sobald die From-Adresse nicht von dem Server ist, auf den der MX-Record zeigt, hast du ein Problem als Spam klassifiziert zu werden. (Dieser Umgang mit From und Sender widerspricht den RFCs,

Das kann ich so nicht bestätigen. Ich habe eine große Zahl an Domains bei denen das genau nicht so ist. Der MX zeigt auf irgend ein Anti-Spam-GW und der Versand erfolgt immer von woanders.

Grundsätzlich kann man auch immer im mit der Domain des Kunden versenden. Vorausgesetzt SPF/DKIM/DMARC-Konfig widerspricht dem nicht und die SMTP-Server Basiskonfiguration (PTR , rDNS, ...) passt.

Wenn Dein Server in der SPF/DKIM/DMARC-Konfig auch noch "mit drin" (DKIM muss man am Sendeserver auch konfigurieren) ist, dann verbessert das den Score nochmal deutlich.

[heisenberg]

Nebenbei: Und ich würde sagen, Google als Maildienst geht auch den Weg, den es schon bei den Webseiten beschreitet:

Content! Es bewertet den Inhalt einer Mail. Wenn da die Qualität nicht stimmt, dann gibt's eine schlechte Punktzahl bei der Spam Bewertung.

[Meillo]

Nachdem ich eine Weile darueber gebruetet habe, glaube ich mein Problem verstanden zu haben. Letztlich trennst du zwischen Versenden und Empfangen von Mail. Paedubucher geht es um das Versenden von Mail. Der MX-Record ist aber fuer's Empfangen da. Ich habe das gekoppelt, was mein Fehler war. Das Versenden und das Empfangen von Mail einer Domain muss auf separate Server verteilbar sein. Darum darf der MX-Record nicht zur Spam-Pruefung bei versandten Mails hergenommen werden. Richtig?

Wenn du es mir noch ein bisschen genauer erklaerst, wuerde mir das beim Verstehen helfen.

[heisenberg]

Du hast zu 100 % richtig geraten. (Mehr möchte ich gerade nicht am Smartphone schreiben, da ich es mittlerweile trotz Streik der Straßenbahnen mittlerweile nach Hause geschafft habe.)

[Meillo]

Okay, aber wie prueft die Anti-Spam-Software, ob die Absende-Mailadresse zum absendenden Mailserver passt? Bei Virtual Hosting ist es (normalerweise) nur ein Domaineintrag fuer die IP-Adresse. Damit alleine kann es also nicht geprueft werden. Ich dachte, dass man dann die Uebereinstimmung des MX-Records pruefen wuerde ... was du aber verneinst, und das macht ja auch Sinn. Man koennte noch den A-Record pruefen. Im Internet habe ich gelesen, dass geprueft werden wuerde, ob rDNS und DNS sich entsprechen. Also rDNS abfragen. (Da kommt dann vielleicht eine andere Domain raus als die Absendeadresse hat.) Dann fuer diese Adresse den A-Record (?) abfragen und schauen ob der wiederum die Ausgangs-IP-Adresse des Mailversenders ist? Stimmt das so?

Das modernere Zeug SPF/DKIM/DMARC kommt dann oben drauf, aber zuerst muss die Basis sitzen. Frueher gab's auch nichts anderes.

Was bedeutet das fuer Paedubucher?

[Meillo]

OT:

(Mehr möchte ich gerade nicht am Smartphone schreiben, da ich es mittlerweile trotz Streik der Straßenbahnen mittlerweile nach Hause geschafft habe.)

Das erklaert auch die gestueckelten Posts. Einstweilen dann mal gute Nacht!

[heisenberg]

Das modernere Zeug SPF/DKIM/DMARC kommt dann oben drauf, aber zuerst muss die Basis sitzen. Frueher gab's auch nichts anderes.

Der Default ohne SPF/DKIM Ist: Jeder darf mit jeder beliebigen E-Mail-Adresse als Absender Mails versenden. Es gibt keine Konfiguration zur Authorisierung im SMTP-Standard, die das festlegt, wer darf mit welcher Adresse senden.

Früher mag es da bei großen Maildiensten vielleicht interne Wege gegeben haben(Zugriffslisten?) könnte ich mir vorstellen. Aber eben nichts, was ein Standard definiert.

[paedubucher]

Das alle Mails eines Unternehmens auch von seiner Domain kommen, finde ich sehr sinnvoll.

Z. B. deswegen, dass der Kunde mit seiner Stammdomain als solcher wahrgenommen wird.

Der einfachste Weg, der mir da einfällt, wäre der, dass der Kunde einen SMTP-Account bereitstellt, mit dem sich dein Server am Kundenmailserver authentifiziert und mit dem die Mails über selbigen verschickt.

Das ist meiner Meinung nach auch eine sehr sinnvolle Option, die sogar zur Debatte stand. Danke, dass du sie erwähnst! Leider wurde das aus sicherheitstechnischen Gründen aufseiten des Kunden abgelehnt.

[paedubucher]

Meine naheliegende Idee wäre es, dass der Kunde einen entsprechenden MX-Record für anwendung.kunde.com einrichtet, der dann auf unseren E-Mail-Server zeigt. Ein entsprechender SPF-Record wäre ebenfalls sinnvoll. So könnten wir auf unserem Postfix einen Benutzer info@anwendung.kunde.com einrichten, und von dem aus die E-Mails versenden. Und das wäre auch meine erste Frage: Wäre dieses Vorgehen grundsätzlich sinnvoll?

IMO ja.

Dann bin ich schon einmal froh, nicht ganz daneben zu liegen.

Der Kunde hat jedoch einen nicht technischen Grund genannt, warum die Mails nicht von anwendung.kunde.com sondern direkt von kunde.com versendet werden sollten. Ich paraphrasiere den Grund mal als "das haben wir sonst auch immer so gemacht". Ich sehe hier zwei Möglichkeiten:

Das effektivste Argument in diesen Faellen ist (leider!) zumeist: Das geht (technisch) nicht anders!

Ja, und in diesem Fall scheint das ja auch wirklich zu stimmen.

• Ich konfiguriere die Domäne kunde.com auf unserem Postfix-Server. So kann ich mit einem entsprechenden Benutzer info@kunde.com E-Mails versenden. Das Problem ist jedoch, dass ausgehende E-Mail-Kommunikation, die nicht über die Kundenanwendung geht, auf dem Mailserver Probleme macht. Der Server glaubt dann, er müsse Adressen wie otto.normalverbraucher@kunde.com auf unserem eigenen Server auflösen. Vielleicht gibt es hier eine Möglichkeit, Postfix so zu konfigurieren, dass er andere Adressen als info@anwendung.com nicht aufzulösen versucht. (Ich bin mit Postfix leider nicht so versiert. Die Frage ist auch eher, ob der Ansatz grundsätzlich sinnvoll wäre.)

Den Mailserver den du im MX-Record angibst muss die Mails fuer die Domain verwalten koennen. AFAIK geht es nicht, dass du zwei Mailserver hast, die jeweils nur eine Teilmenge der Adressen verwalten kann, naemlich info@ bei dir und alles andere beim Kunde.

Das ist einleuchtend, und ich fand die Idee auch etwas gewagt. Aber das Experiment hat es mir noch einmal verdeutlicht.

• Ich konfiguriere keine weitere Domäne auf unserem Postfix-Server, sondern bloss die Adresse kunde@arbeitgeber.com, von der aus dann die Applikation E-Mails verschickt. Als eigentlicher Benutzer wird dann die besagte Adresse verwendet, der Sender-Header wird aber als info@kunde.com angegeben. Das geht ja mit SMTP technisch problemlos. Die Frage ist aber hier, ob ich dadurch vielleicht die Reputation unseres E-Mail-Servers schädigen könnte, was ich natürlich nicht will. Genügt hier ein entsprechender SPF-Record aufseiten des Kunden, um dies zu verhindern?

Laut RFC ist Sender der technische Absender, in dem Fall also <info@anwendung.kunde.com>. From ist der inhaltliche Absender, also <info@kunde.com>. (Dann kann man noch Reply-To setzen.)

Die (globale) Option reject_sender_login_mismatch, die sinnvollerweise auf unsere Server konfiguriert ist, verhindert dies.

Das Problem ist, dass AFAIK DMARC Sender-Header schlichtweg ignoriert, weshalb die ganzen Mailinglisten kaputt gehen. Sobald die From-Adresse nicht von dem Server ist, auf den der MX-Record zeigt, hast du ein Problem als Spam klassifiziert zu werden. (Dieser Umgang mit From und Sender widerspricht den RFCs, nach denen From z.B. auch mehrere Personen/Adressen sein koennen, dann muss es aber einen Sender geben, der immer nur genau eine Adresse enthaelt. Das aber nur nebenbei.)

Hier muss ich mich noch genauer einlesen. Aber es ist naheliegend, dass dieser Mismatch problematisch sein kann. Man bedenke nur die Briefpost-Analogie.

Meine Empfehlung waere, dem Kunden klarzumachen, dass nur dein obiger Vorschlag moeglich ist, weil das andere entweder technisch nicht geht oder die Mails als Spam klassifiziert werden. (Falls es ihm dennoch so wichtig waere, sollte er gehoerig Kohle rueberwachsen lassen, dann kann man sich die Umwege mit all ihren Nachteilen nochmal ueberlegen. Empfehlen wuerde ich sie nicht; die werden nur Probleme erzeugen, Fehlerquellen generieren, instabil sein.)

Das ist jetzt auch meine Strategie. Auch Geld sollte hier kein Argument sein, da dadurch die Konfiguration des Mailservers sicherheitstechnisch geschwächt werden müsste. Mein Chef mag es bestimmt nicht, wenn ich von seinem Absender aus Mails verschicken könnte.

[Meillo]

• Ich konfiguriere keine weitere Domäne auf unserem Postfix-Server, sondern bloss die Adresse kunde@arbeitgeber.com, von der aus dann die Applikation E-Mails verschickt. Als eigentlicher Benutzer wird dann die besagte Adresse verwendet, der Sender-Header wird aber als info@kunde.com angegeben. Das geht ja mit SMTP technisch problemlos. Die Frage ist aber hier, ob ich dadurch vielleicht die Reputation unseres E-Mail-Servers schädigen könnte, was ich natürlich nicht will. Genügt hier ein entsprechender SPF-Record aufseiten des Kunden, um dies zu verhindern?

Laut RFC ist Sender der technische Absender, in dem Fall also <info@anwendung.kunde.com>. From ist der inhaltliche Absender, also <info@kunde.com>. (Dann kann man noch Reply-To setzen.)

Die (globale) Option reject_sender_login_mismatch, die sinnvollerweise auf unsere Server konfiguriert ist, verhindert dies.

Das Problem ist, dass AFAIK DMARC Sender-Header schlichtweg ignoriert, weshalb die ganzen Mailinglisten kaputt gehen. Sobald die From-Adresse nicht von dem Server ist, auf den der MX-Record zeigt, hast du ein Problem als Spam klassifiziert zu werden. (Dieser Umgang mit From und Sender widerspricht den RFCs, nach denen From z.B. auch mehrere Personen/Adressen sein koennen, dann muss es aber einen Sender geben, der immer nur genau eine Adresse enthaelt. Das aber nur nebenbei.)

Hier muss ich mich noch genauer einlesen. Aber es ist naheliegend, dass dieser Mismatch problematisch sein kann. Man bedenke nur die Briefpost-Analogie.

Die Briefpost-Analogie ist doch gerade, dass mehrere Personen zusammen einen Brief diktieren, der dann von der Sekretaerin getippt und verschickt wird. Im From-Header waeren dann alle inhaltlichen Autoren (also all diejenigen, die ihn unterschreiben); im Sender-Header waere die Sekretaerin, die den Brief technisch verschickt. Diese Briefpost-Analogie, die RFC 822 (und Nachfolger 2822, 5322) zugrunde liegt, ist in den allermeisten MUAs so nicht ungesetzt worden.

Das eigentliche Problem ist, dass MUAs den Sender-Header vollkommen ignorieren und ignoriert haben. Durch diese schlechte Entscheidung haben wir nun eine Situation in der er auch von allen anderen Mailkomponenten ignoriert wird und das fuehrt zu Problemen die man nicht haette, haette man ihn nicht ignorieren wuerde. Die Email-RFCs sind so hervorragend designt. RFC 822 und auch MIME sind erstklassige strukturierte Beschreibungen der Anwendungs-Domaene Brief-Kommunikation. Sie umfassen so gut wie alles was diese Domaene umfasst, und MIME kann sogar Zeitschriften und Multimedia-Content abbilden. Die Anwendungsprogramme haben aber nur ein vereinfachtes Teilset daraus implementiert, weil sie meinten, das wuerde die Sache einfacher machen. Dabei haben sie ignoriert, dass diese Komplexitaet nicht zufaellig vorhanden sondern der Anwendungs-Domaene inherent ist. Man haette sie nicht weglassen duerfen. Man haette Sender-Header in den MUAs anzeigen muessen (wenn sie vorhanden sind, weil sie vom From-Header abweichen). Heute stecken wir aber in der Sitaution fest, dass der From-Header sinngemaess gar kein From-Header mehr ist, sondern nur ein Sender-Header. All die Gruende und Anwendungsfaelle, die die Unterscheidung urspruenglich noetig gemacht haben, koennen nun nicht mehr abgedeckt werden. Darunter fallen Mailinglisten ebenso wie deine Situation. Darum stecken wir heute in Workarounds fest und muessen die tatsaechliche Komplexitaet nach aussen hin einfacher erscheinen lassen als sie ist, damit sie den beschraenkten Konzepten entspricht, die durch die Software auch implementiert sind.

[paedubucher]

Laut RFC ist Sender der technische Absender, in dem Fall also <info@anwendung.kunde.com>. From ist der inhaltliche Absender, also <info@kunde.com>. (Dann kann man noch Reply-To setzen.)

Die (globale) Option reject_sender_login_mismatch, die sinnvollerweise auf unsere Server konfiguriert ist, verhindert dies.

Das Problem ist, dass AFAIK DMARC Sender-Header schlichtweg ignoriert, weshalb die ganzen Mailinglisten kaputt gehen. Sobald die From-Adresse nicht von dem Server ist, auf den der MX-Record zeigt, hast du ein Problem als Spam klassifiziert zu werden. (Dieser Umgang mit From und Sender widerspricht den RFCs, nach denen From z.B. auch mehrere Personen/Adressen sein koennen, dann muss es aber einen Sender geben, der immer nur genau eine Adresse enthaelt. Das aber nur nebenbei.)

Hier muss ich mich noch genauer einlesen. Aber es ist naheliegend, dass dieser Mismatch problematisch sein kann. Man bedenke nur die Briefpost-Analogie.

Die Briefpost-Analogie ist doch gerade, dass mehrere Personen zusammen einen Brief diktieren, der dann von der Sekretaerin getippt und verschickt wird. Im From-Header waeren dann alle inhaltlichen Autoren (also all diejenigen, die ihn unterschreiben); im Sender-Header waere die Sekretaerin, die den Brief technisch verschickt. Diese Briefpost-Analogie, die RFC 822 (und Nachfolger 2822, 5322) zugrunde liegt, ist in den allermeisten MUAs so nicht ungesetzt worden.

Bei der Briefpost-Analogie habe ich gar nicht so weit gedacht. Ich meinte eher, dass es problematisch ist, einen Absender anzugeben, unter dem ich dann überhaupt nicht mehr auffindbar bin. Die Sekretärin wäre da eher ein Proxy, und würde mir die Antwort selbstverständlich wieder zukommen lassen.

Das eigentliche Problem ist, dass MUAs den Sender-Header vollkommen ignorieren und ignoriert haben. Durch diese schlechte Entscheidung haben wir nun eine Situation in der er auch von allen anderen Mailkomponenten ignoriert wird und das fuehrt zu Problemen die man nicht haette, haette man ihn nicht ignorieren wuerde. Die Email-RFCs sind so hervorragend designt. RFC 822 und auch MIME sind erstklassige strukturierte Beschreibungen der Anwendungs-Domaene Brief-Kommunikation. Sie umfassen so gut wie alles was diese Domaene umfasst, und MIME kann sogar Zeitschriften und Multimedia-Content abbilden. Die Anwendungsprogramme haben aber nur ein vereinfachtes Teilset daraus implementiert, weil sie meinten, das wuerde die Sache einfacher machen. Dabei haben sie ignoriert, dass diese Komplexitaet nicht zufaellig vorhanden sondern der Anwendungs-Domaene inherent ist. Man haette sie nicht weglassen duerfen. Man haette Sender-Header in den MUAs anzeigen muessen (wenn sie vorhanden sind, weil sie vom From-Header abweichen). Heute stecken wir aber in der Sitaution fest, dass der From-Header sinngemaess gar kein From-Header mehr ist, sondern nur ein Sender-Header. All die Gruende und Anwendungsfaelle, die die Unterscheidung urspruenglich noetig gemacht haben, koennen nun nicht mehr abgedeckt werden. Darunter fallen Mailinglisten ebenso wie deine Situation. Darum stecken wir heute in Workarounds fest und muessen die tatsaechliche Komplexitaet nach aussen hin einfacher erscheinen lassen als sie ist, damit sie den beschraenkten Konzepten entspricht, die durch die Software auch implementiert sind.

In meinem Anwendungscode kann ich die beschriebene Problematik durchaus nachvollziehen. Das eingesetzte Framework bietet mir auf der API-Ebene nur einen Sender- und keinen From-Header. Da wird eine Enfachheit suggeriert, die nicht gegeben ist. Für ein tiefergehendes Verständnis muss ich mich sicher mal gründlich in die RFCs einlesen. Das Einlesen in MIME wäre aber sicher lohnend.

[Meillo]

OT:

Das Einlesen in MIME wäre aber sicher lohnend.

... aber auch aufwaendig. Das sind vier oder fuenf RFCs, die jeweils einen Teil abdecken. Natuerlich ist da auch viel Kodierungszeug dabei, weil MIME den Umgang mit nicht-textuellen Inhalten beitraegt. Das eigentlich interessante finde ich aber die Inhaltsstruktur, die man aufbauen kann, gleichzeitig anzuzeigende oder alternativ anzuzeigende Inhalte. Man kann gut nachvollziehen, dass hier auch Magazine mit Text und Bildern, Videos, Alternativtext, Hintergrundton zum Text und dergleichen im Blick war, als MIME designt worden ist.

Email nutzt nur einen kleinen Teil davon, naemlich typischerweise nur eine serielle Liste von Anhaengen plus text/plain und text/html als Alternativauswahl. Die MIME-Implementierung von MH/nmh/mmh kann deutlich mehr. Sie war eine der ersten Implementierungen von MIME und ist eng an die RFCs gekoppelt. Das Mind-Model der Email-Anhaenge ist erst spaeter populaer geworden. Nmh/mmh ist nicht darauf beschraenkt; dort koennen fast beliebige MIME-Strukturen aufgebaut und weitgehend auch dargestellt werden.

Mit modernem Emailing hat das nicht mehr viel zu tun, aber konzeptionell ist das reizvoll. Die Welt haette sich in diese Richtung entwickeln koennen, sie hat es aber nicht getan.

[paedubucher]

Das UNIX and Linux System Administration Handbook, das in der 5. Ausgabe von 2017 recht aktuell ist, enthält ein Kapitel über E-Mail. Ich werde das als Einstieg lesen. (Leider liegt es im Büro, wo ich derzeit nur selten vorbeischaue.) Dann kann ich nachher immer noch die RFCs durchlesen.

Zu meinem ursprünglichen Problem habe ich noch einen guten Grund gefunden, warum der erste Lösungsvorschlag schlecht ist: Wenn wir von @kunde.com Mails versenden, und unser E-Mail-Server auch noch per SPF-Eintrag dazu legitimiert wird, können wir auch E-Mails von ceo@kunde.com verschicken, ohne dass es für den Client sehr verdächtig aussieht. Ich warte jetzt ab, ob der Kunde doch noch auf eine Subdomain einschwenkt.