22
SMTP-Relay Anpassung
Moin,
siehe hier: IONOS SMTP-Relay Anpassung ab 15.01.2024 nötig
folgende Konfiguration ist gegeben:
hausinterner E-Mail Server -> übergibt ausgehende E-Mails per SMTP an einen Linux SmartRelay -> übergibt die Mails nach Authentifizierungan einen E-Mail Provider (wo die Domäne domain.de liegt).
Die Authentifizierung zum E-Mail Provider hin erfolgt mit einem Sammelkonto "mailversand@domain.de" in der etc/postfix/smtp_auth.
Nun möchte der E-Mail Provider, daß sich jeder aus der Domäne domain.de mit seinen eigenen Zugangsdaten authentifiziert, und nicht über das eingerichtete und hinterlegte Sammelkonto.
Wie mache ich das am besten unter Postfix ? Ich bräuchte einen Denkanstoß bzw. Schubs in die entsprechende Richtung.
Danke
siehe hier: IONOS SMTP-Relay Anpassung ab 15.01.2024 nötig
folgende Konfiguration ist gegeben:
hausinterner E-Mail Server -> übergibt ausgehende E-Mails per SMTP an einen Linux SmartRelay -> übergibt die Mails nach Authentifizierungan einen E-Mail Provider (wo die Domäne domain.de liegt).
Die Authentifizierung zum E-Mail Provider hin erfolgt mit einem Sammelkonto "mailversand@domain.de" in der etc/postfix/smtp_auth.
Nun möchte der E-Mail Provider, daß sich jeder aus der Domäne domain.de mit seinen eigenen Zugangsdaten authentifiziert, und nicht über das eingerichtete und hinterlegte Sammelkonto.
Wie mache ich das am besten unter Postfix ? Ich bräuchte einen Denkanstoß bzw. Schubs in die entsprechende Richtung.
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 42728629256
Url: https://administrator.de/forum/smtp-relay-anpassung-42728629256.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
22 Kommentare
Neuester Kommentar
Schau mal, so könnte das mit Postfix funktionieren:
Es gibt auch eine einfachere Möglichkeit, dies zu erreichen, indem Sie die smtp_sender_dependent_authentication-Option in Postfix verwenden. Hier ist eine einfachere Konfiguration:
Öffnen Sie Ihre Postfix-Konfigurationsdatei (normalerweise unter /etc/postfix/main.cf) in einem Texteditor.
Fügen Sie die folgenden Zeilen hinzu (Quelle: ChatGPT):
Erstellen Sie die Datei /etc/postfix/sender_relayhosts und fügen Sie die Absender-Relay-Host-Zuordnungen hinzu:
Hierbei wird angenommen, dass die Relay-Hosts die Authentifizierung über den Standard-SMTP-Port 587 unterstützen.
Erstellen Sie die Datei /etc/postfix/sasl_passwd und fügen Sie die SMTP-Authentifizierungsinformationen hinzu:
Führen Sie den folgenden Befehl aus, um die sasl_passwd-Datei zu hashen:
Ändern Sie die Berechtigungen der sasl_passwd.db-Datei:
Konfigurieren Sie Postfix, um die erstellten Dateien zu verwenden:
Aktualisieren Sie die Postfix-Konfiguration:
Dieser Ansatz ermöglicht es Ihnen, eine spezifische SMTP-Authentifizierung für jeden Absender festzulegen, indem Sie den entsprechenden Relay-Host konfigurieren. Beachten Sie, dass dies eine einfachere Option ist, aber immer noch sicherstellen sollte, dass Sie sensible Informationen, wie Passwörter, sicher speichern und entsprechende Berechtigungen setzen.
Es gibt auch eine einfachere Möglichkeit, dies zu erreichen, indem Sie die smtp_sender_dependent_authentication-Option in Postfix verwenden. Hier ist eine einfachere Konfiguration:
Öffnen Sie Ihre Postfix-Konfigurationsdatei (normalerweise unter /etc/postfix/main.cf) in einem Texteditor.
Fügen Sie die folgenden Zeilen hinzu (Quelle: ChatGPT):
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relayhostsuser1@example.com [smtp.example.com]:587
user2@example.com [smtp.anotherexample.com]:587Erstellen Sie die Datei /etc/postfix/sasl_passwd und fügen Sie die SMTP-Authentifizierungsinformationen hinzu:
[smtp.example.com]:587 smtpuser1:password1
[smtp.anotherexample.com]:587 smtpuser2:password2postmap hash:/etc/postfix/sasl_passwdchmod 600 /etc/postfix/sasl_passwd.dbsmtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yessudo postfix reload
ChatGPT bzw. Quelle bitte kennzeichnen 😉
Ich würde ja den Linux Server ja stattdessen direkt zustellen lassen als wieder die Krücke über einen Smarthost zu gehen, sofern der eine öffentliche IP aus einem non DialIn Bereich hat ...
Oder sich einen Provider suchen der einen nicht so gängelt.
Ich wette das bei IONOS jetzt so viel Kritik aufläuft das sie es vermutlich wieder zurück nehmen oder zumindest eine Alternative anbieten. Ansonsten laufen denen wohl diverse Kunden über die Feiertage davon.
Ich würde ja den Linux Server ja stattdessen direkt zustellen lassen als wieder die Krücke über einen Smarthost zu gehen, sofern der eine öffentliche IP aus einem non DialIn Bereich hat ...
Oder sich einen Provider suchen der einen nicht so gängelt.
Ich wette das bei IONOS jetzt so viel Kritik aufläuft das sie es vermutlich wieder zurück nehmen oder zumindest eine Alternative anbieten. Ansonsten laufen denen wohl diverse Kunden über die Feiertage davon.
3
Das mit den mehreren Auth-Konten in Postfix ist ja auch nur für den Fall sinnvoll wenn man das im eigenen Netz laufen hat. Ein vServer bei einem Provider kann den Versand ja direkt erledigen, sofern SPF & Co. korrekt konfiguriert sind.
Eine gute gangbare Option wäre ja, explizit ein E-Mailkonto für ein Smartrelay zu erstellen zu können, bei dem dann nur die Absenderdomain und nicht die komplette Absenderadresse geprüft wird.
Eine gute gangbare Option wäre ja, explizit ein E-Mailkonto für ein Smartrelay zu erstellen zu können, bei dem dann nur die Absenderdomain und nicht die komplette Absenderadresse geprüft wird.
Zitat von @DerNixWusste:
Nun möchte der E-Mail Provider, daß sich jeder aus der Domäne domain.de mit seinen eigenen Zugangsdaten authentifiziert, und nicht über das eingerichtete und hinterlegte Sammelkonto.
Nun möchte der E-Mail Provider, daß sich jeder aus der Domäne domain.de mit seinen eigenen Zugangsdaten authentifiziert, und nicht über das eingerichtete und hinterlegte Sammelkonto.
Das ist doch sehr fraglich. Es hat offenbar noch keiner den ominösen Hinweis erhalten, der eine solche selbstverstänliche Konfiguration nutzt bzw. konkrete Informationen zu seinem Vorgehen liefern kann, oder hast Du?
Die Bedeutung der verlinkten allgemeinen Information hängt davon ab, ob deren Autor wirklich weiß, was ein "Postfach" ist. Dazu habe ich schon viel Flüsterpost erlebt. Die falschen Instruktionen deuten darauf hin:
Wenn Sie in den Einstellungen Ihres E-Mail-Programms eine abweichende Absenderadresse hinterlegt haben, müssen Sie diese durch die E-Mail-Adresse ersetzen, die Sie für den E-Mail-Empfang angegeben haben.
Es würde Betroffenen nichts nutzen, da die Absenderadresse gleich mit der Empfangsadresse sein kann und immer noch verschieden mit dem SMTP-Nutzer.
Ganz unten heißt es dann:
Wenn Sie die bisher verwendete Absenderadresse als Weiterleitungsadresse eingerichtet haben und diese eine abweichende Domain enthält, kann diese Weiterleitungsadresse ab dem 15.01.2024 nicht mehr als Absenderadresse verwendet werden.
Also mit der gleichen Domain würde sie weiterhin funktionieren?
Edit: Ich nehme alles zurück und behaupte das Gegenteil. In der Anleitung zu Mail-Clients heißt es:
Sie haben bei IONOS die E-Mail-Adresse max.mustermann@example.com erstellt und verwenden in Thunderbird die E-Mail-Adresse kontakt@example.org als Absender. In diesem Fall müssen Sie statt der Absenderadresse kontakt@example.org die E-Mail-Adresse max.mustermann@example.com verwenden.
Das wäre in der Tat misslich, die Lösung ist die Kündigung.
Wie mache ich das am besten unter Postfix ? Ich bräuchte einen Denkanstoß bzw. Schubs in die entsprechende Richtung.
Die individualisierte Authentifizierung am Smarthost ist hier gut beschrieben (und entspricht im Prinzip dem obigen ChatGPT-Lösungsvorschlag):https://wiki.ubuntuusers.de/Postfix/#Korrekten-Absender-setzen
Viele Grüße, commodity
Danke für die vielen Tips - werde ich ausprobieren und Feedback geben.
Zitat von @c.r.s.:
Edit: Ich nehme alles zurück und behaupte das Gegenteil. In der Anleitung zu Mail-Clients heißt es:
Edit: Ich nehme alles zurück und behaupte das Gegenteil. In der Anleitung zu Mail-Clients heißt es:
Sie haben bei IONOS die E-Mail-Adresse max.mustermann@example.com erstellt und verwenden in Thunderbird die E-Mail-Adresse kontakt@example.org als Absender. In diesem Fall müssen Sie statt der Absenderadresse kontakt@example.org die E-Mail-Adresse max.mustermann@example.com verwenden.
Ach, da hatte ich mich auch verlesen, es sind ja unterschiedliche Domains. Wie dem auch sei, individuelle Authentifizierung ist für Unternehmen meines Erachtens nicht praktikabel.
individuelle Authentifizierung ist für Unternehmen meines Erachtens nicht praktikabel.
Warum nicht? Für ein Kleinunternehmen kann ich doch auch mal ein paar Accounts mappen. Da ändert sich ja auch eher selten was.Ein größeres Unternehmen betreibt seinen Mailserver ohnehin nicht mit Smarthost, sondern hat einen eigenen Mailserver im RZ oder (wie zB ich es vorziehe) eine Kaskade von internem und externem (RZ-)Mailserver, die direkt verbunden sind. Da tritt das Problem dann gar nicht mehr auf.
Viele Grüße, commodity
Zitat von @commodity:
individuelle Authentifizierung ist für Unternehmen meines Erachtens nicht praktikabel.
Warum nicht? Für ein Kleinunternehmen kann ich doch auch mal ein paar Accounts mappen. Da ändert sich ja auch eher selten was.Hätte ich früher auch gesagt: Technisch kein Problem, organisatorisch machbar.
Nach dem Verlassen der eigenen und einer Reise durch diverse Bubbles, rate ich aber grundsätzlich von allem ab, was nicht äußerst niedrigschwellig Instand zu halten ist:
Zuerst sind sich alle einig, dass sich selten was ändert. Dann ändert sich was, und weil das nicht so selten ist wie erwartet, wird darauf verzichtet, das betreffende Konto ordnungsgemäß außer Betrieb zu nehmen. Schließlich wächst das Unternehmen, und die Lösung wird noch mit 150 Mitarbeitern mitgeschleift, weil die Entscheidungsträger das Problem nicht sehen. Der Praktikant, dem die unliebsame und nie automatisierte Administration aufs Auge gedrückt wird, verwendet ab Nutzer Nr. 48 dasselbe Passwort, weil es die Nutzer ja eh nicht kennen. Das Passwort genügt gerade so den Anforderungen des Anbieters, denn manchen Menschen fällt es leichter, P@$$w0rd in einem Passwort-Manager zu hinterlegen als 8mM%>2na. Der nächste Praktikant hilft dann dem Nutzer, der unterwegs nicht ins VPN kommt, mit dem Zugriff auf das Web-Mail-Portal von IONOS aus...
Ein größeres Unternehmen betreibt seinen Mailserver ohnehin nicht mit Smarthost, sondern hat einen eigenen Mailserver im RZ oder (wie zB ich es vorziehe) eine Kaskade von internem und externem (RZ-)Mailserver, die direkt verbunden sind. Da tritt das Problem dann gar nicht mehr auf.
Oder misstraut dem Ganzen, und betreibt seinen eigenen Mailserver Inhouse - wie wir. Dann tritt es doch auf
Und der Mailserver ist Tobit David, die seit Jahren darüber "nachdenken", ob sie ein DKIM Signer Plugin für Tobit programmieren. Nun weisst Du, wieso hinter unseren Mailserver ein Linux Smarthost mit OpenDKIM steht
Mailserver ist Tobit David...
ich hatte sowas schon geahnt. Und nein:betreibt seinen eigenen Mailserver Inhouse - wie wir. Dann tritt es doch auf
Das ist falsch. Ich betreibe Mailserver immer auch inhouse. Schon weil ich altmodisch gern die Daten vor Ort habe, das Backup kontrollierbarer ist, der Spamfilter den der kommerziellen Produkte abhängt und und und Das Problem bei Dir tritt auf, weil Du
a) falsch (auf die alte Tour) authentifizierst und zudem
b) einen Smarthost verwendest statt eines selbst gehosteten Versandservers.
Einer der Fehler, a) oder b) müssen korrigiert werden. In Deinem Fall, da Du sicher beim Smarthost bleiben möchtest, der zu a). Lösung im obigen Link bei Ubuntuusers.
Viele Grüße, commodity
Du hast ja Recht - bei mir ist es entweder Faulheit, oder seit Jahren eingefahrene Lösungen
- bei wem ist das nicht so ...Zum Glück lässt sich das ja hier leicht beheben.
Wenn Du mal an den internen Mailserver ran willst (oder einen externen selbst hosten):
https://thomas-leister.de/mailserver-debian-buster/
Viele Grüße, commodity
Hallo zusammen,
wir gehören leider auch zu den Dummen, die von der Änderung von IONOS betroffen sind.
Wir setzen hier ein Linux-System ein, mit dem 'Paket' iRedMail. Das basiert auf fetchmail, postfix, dovcot, und noch ein wenig mehr Schnickschnack. Intern nutzen wir dann IMAP.
Eingehende Mails von extern holen wir für die einzelnen Postfächer mit fetchmail per pop3 von IONOS ab. Da sind wir save.
Es geht halt um ausgehende Mails nach extern. Die senden wir heute mit smarthost smtp.ionos.de mit einem extra Konto - nennen wir es 'postbote@example.com'. Damit gehen natürlich 'otto@example.com' genauso raus wie 'hugo@example.com' oder 'paul@example.com'. Das ist - so mein Verständnis der Änderung' - ist ab 15.1. nicht mehr möglich.
Ich habe mir die Lösung von @schnuffchen ebenso angesehen wie den Verweis von @commodity
Ich wäre tatsächlich verwundert wenn postfix das nicht irgendwie könnte aber ich bin - wie so oft - scheinbar zu blöd die oft ultra allgemein gehaltenen HowTos der Linuxer zu verstehen.
Das was @schnuffchen beschreibt ist nach meinem Verständnis ein Weg, wie ich postfix sagen kann, er soll abhängig von der Sender-Mail-Domain unterschiedliche relay hosts verwenden. Ich kann dann je relay host dessen Accountdaten hinterlegen. Wenn ich mit unterschiedliche Maildomains hantiere (example.com, example.de etc) ist das erst mal gut; hilft aber beim IONOS-Problem nicht ausschließlich.
Das Problem ist aber, dass otto nicht mehr über denn Account postbote versenden darf. postfix muss sich auch als otto bei smtp.ionos.de authentisieren.
Da kommt nun der Verweis von @commodity ins Spiel mit sender_canonical
Da wir intern ebenfalls als Usernamen die korrekte Mailadresse verwenden müsste da z.B. in /etc/postfix/sender_canonical stehen:
otto@example.com otto@example.com
hugo@example.com hugo@example.com
paul@example.com paul@example.com
Richtig?
Soweit so gut. Gehen wir mal davon aus, dass das so tut.
Anhand der Domain example.com findet postfix heraus welchen relay er ansprechen muss.
Über den Eintrag in sender_canonical weiß postfix welchen Accountname er verwenden soll. (Ist das denn so? Der account ist eigentlich am smarthost in /etc/postfix/sasl_passwd hinterlegt.)
otto hat aber auf dem Mailserver bei IONOS ein anderes Passwort als auf unserem internen Mailserver.
Und nun? Irgendwo muss das Passwort doch noch herkommen. Bisher steht das nur in ottos fetchmail-Konfigurationsdatei im Klartext.
Da hört es bei mir dann auf. Kann da jemand Licht ins Dunkle bringen?
Gruß
Frank
wir gehören leider auch zu den Dummen, die von der Änderung von IONOS betroffen sind.
Wir setzen hier ein Linux-System ein, mit dem 'Paket' iRedMail. Das basiert auf fetchmail, postfix, dovcot, und noch ein wenig mehr Schnickschnack. Intern nutzen wir dann IMAP.
Eingehende Mails von extern holen wir für die einzelnen Postfächer mit fetchmail per pop3 von IONOS ab. Da sind wir save.
Es geht halt um ausgehende Mails nach extern. Die senden wir heute mit smarthost smtp.ionos.de mit einem extra Konto - nennen wir es 'postbote@example.com'. Damit gehen natürlich 'otto@example.com' genauso raus wie 'hugo@example.com' oder 'paul@example.com'. Das ist - so mein Verständnis der Änderung' - ist ab 15.1. nicht mehr möglich.
Ich habe mir die Lösung von @schnuffchen ebenso angesehen wie den Verweis von @commodity
Ich wäre tatsächlich verwundert wenn postfix das nicht irgendwie könnte aber ich bin - wie so oft - scheinbar zu blöd die oft ultra allgemein gehaltenen HowTos der Linuxer zu verstehen.
Das was @schnuffchen beschreibt ist nach meinem Verständnis ein Weg, wie ich postfix sagen kann, er soll abhängig von der Sender-Mail-Domain unterschiedliche relay hosts verwenden. Ich kann dann je relay host dessen Accountdaten hinterlegen. Wenn ich mit unterschiedliche Maildomains hantiere (example.com, example.de etc) ist das erst mal gut; hilft aber beim IONOS-Problem nicht ausschließlich.
Das Problem ist aber, dass otto nicht mehr über denn Account postbote versenden darf. postfix muss sich auch als otto bei smtp.ionos.de authentisieren.
Da kommt nun der Verweis von @commodity ins Spiel mit sender_canonical
Da wir intern ebenfalls als Usernamen die korrekte Mailadresse verwenden müsste da z.B. in /etc/postfix/sender_canonical stehen:
otto@example.com otto@example.com
hugo@example.com hugo@example.com
paul@example.com paul@example.com
Richtig?
Soweit so gut. Gehen wir mal davon aus, dass das so tut.
Anhand der Domain example.com findet postfix heraus welchen relay er ansprechen muss.
Über den Eintrag in sender_canonical weiß postfix welchen Accountname er verwenden soll. (Ist das denn so? Der account ist eigentlich am smarthost in /etc/postfix/sasl_passwd hinterlegt.)
otto hat aber auf dem Mailserver bei IONOS ein anderes Passwort als auf unserem internen Mailserver.
Und nun? Irgendwo muss das Passwort doch noch herkommen. Bisher steht das nur in ottos fetchmail-Konfigurationsdatei im Klartext.
Da hört es bei mir dann auf. Kann da jemand Licht ins Dunkle bringen?
Gruß
Frank
Hatte ich nicht diesen Link verlinkt? Ansonsten steht's 10 cm höher
"Authentifizierung am Smarthost" - geht über die /etc/postfix/sasl_password
Da kannst Du unterschiedliche Relayhosts sowie deren User und Passwörter angeben. Deshalb steht da drüber
"nach diesem Muster". Die Passwörter sind dann die von 1&1.
Oder auch im Original:
"smtp_sasl_password_maps (default: empty): Optional Postfix SMTP client lookup tables with one username:password entry per sender, remote hostname or next-hop domain."
Wenn Du bereits die korrekten Absender verwendest, musst Du IMO auch nichts mappen. Die sender_canonical_maps - Zeile brauchst Du in Deinem Fall IMO nicht. Wo sich nichts ändert, muss auch nichts gemappt werden
Wenn Du die
Während MS (Apple auch) sich sehr bemühen, die Leute mit standardfernem Wording für dumm zu verkaufen.
Gut lernt man hier auch mit Thomas Leister. Ist aber ähnlich wie bei den Tutorials des Kollegen @aqui: Mal kurz drüberschauen und losklicken ist nicht. Man muss sich schon etwas reinarbeiten. Aber dafür ist man ja Administrator, oder?
Viele Grüße, commodity
"Authentifizierung am Smarthost" - geht über die /etc/postfix/sasl_password
Da kannst Du unterschiedliche Relayhosts sowie deren User und Passwörter angeben. Deshalb steht da drüber
"nach diesem Muster". Die Passwörter sind dann die von 1&1.
Oder auch im Original:
"smtp_sasl_password_maps (default: empty): Optional Postfix SMTP client lookup tables with one username:password entry per sender, remote hostname or next-hop domain."
Wenn Du bereits die korrekten Absender verwendest, musst Du IMO auch nichts mappen. Die sender_canonical_maps - Zeile brauchst Du in Deinem Fall IMO nicht. Wo sich nichts ändert, muss auch nichts gemappt werden
Wenn Du die
ultra allgemein gehaltenen HowTos der Linuxer
nicht verstehst, musst Du Dir Verständnis verschaffen. Dafür gibt's dann Manpages und Dokumentationen. Kennst Du doch auch von Windows. Auch dort klickt ein guter Admin nicht einfach rum, sondern versteht, was sich hinter einem Kreuzchen verbirgt. Der Vorteil von Linux ist hier, dass die Dinge meist korrekt (also standardkonform) benannt sind. password_maps sind dann auch password maps und sender_maps sind sender maps Während MS (Apple auch) sich sehr bemühen, die Leute mit standardfernem Wording für dumm zu verkaufen.Gut lernt man hier auch mit Thomas Leister. Ist aber ähnlich wie bei den Tutorials des Kollegen @aqui: Mal kurz drüberschauen und losklicken ist nicht. Man muss sich schon etwas reinarbeiten. Aber dafür ist man ja Administrator, oder?
Viele Grüße, commodity
Oh, entschuldigung, ich habe offenbar den Knicks vergessen...
Auszug aus der Mail von IONOS
"Bitte stellen Sie bis zum 14.01.2024 sicher, dass in den Einstellungen Ihrer verwendeten Software identische E-Mail-Adressen für den Absender und die Authentifizierung am Postausgangsserver (SMTP) gesetzt sind. Wenn diese Adressen nicht übereinstimmen, werden betroffene E-Mails ab dem 15.01.2024 von unseren SMTP-Servern mit der Fehlermeldung „Sender address is not allowed.“ abgelehnt und nicht versendet."
Bedeutet in meiner Lesart: Wenn otto einen Mail versenden will muss er sich auch als otto gegen den smtp.ionos.de authentisieren. Bedeutet nicht nur in meiner Lesart das aus für relaying und smarthost.
Wir arbeiten nur mit einer einzige Mail-Domain. daher einfach:
/etc/postfix/main.cf
/etc/postfix/sasl_passwd:
Das ist das was Du eine hinreichende Lösung nennst wenn ich Dich richtig verstehe.
Das ist normales relaying.
Nur wo kommen jetzt hugo, otto und paul ins spiel?
So meldet sich postfix als postbote beim IONOS-Server an und sendet eine Mail mit From:otto@example.com
Finde den Fehler bezüglich der Forderung von IONOS.
Gruß Frank
Auszug aus der Mail von IONOS
"Bitte stellen Sie bis zum 14.01.2024 sicher, dass in den Einstellungen Ihrer verwendeten Software identische E-Mail-Adressen für den Absender und die Authentifizierung am Postausgangsserver (SMTP) gesetzt sind. Wenn diese Adressen nicht übereinstimmen, werden betroffene E-Mails ab dem 15.01.2024 von unseren SMTP-Servern mit der Fehlermeldung „Sender address is not allowed.“ abgelehnt und nicht versendet."
Bedeutet in meiner Lesart: Wenn otto einen Mail versenden will muss er sich auch als otto gegen den smtp.ionos.de authentisieren. Bedeutet nicht nur in meiner Lesart das aus für relaying und smarthost.
Wir arbeiten nur mit einer einzige Mail-Domain. daher einfach:
/etc/postfix/main.cf
[schnipp]
relayhost = smtp.ionos.de:587
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_security_options = noanonymous
[schnapp]/etc/postfix/sasl_passwd:
smtp.ionos.de postbote@example.com:postbotes_passwortDas ist das was Du eine hinreichende Lösung nennst wenn ich Dich richtig verstehe.
Das ist normales relaying.
Nur wo kommen jetzt hugo, otto und paul ins spiel?
So meldet sich postfix als postbote beim IONOS-Server an und sendet eine Mail mit From:otto@example.com
Finde den Fehler bezüglich der Forderung von IONOS.
Gruß Frank
Nur wo kommen jetzt hugo, otto und paul ins spiel?
Na in Zeile 2, 3 und 4 Deiner sasl_passwd 1 smtp.ionos.de postbote@example.com:postbotes_passwort
2 smtp.ionos.de hugo@example.com:hugos_passwort
3 smtp.ionos.de otto@example.com:ottos_passwort
und nach dem Editieren immer schön ans postmap denken
Viele Grüße, commodity
Zitat von @commodity:
1 smtp.ionos.de postbote@example.com:postbotes_passwort
2 smtp.ionos.de hugo@example.com:hugos_passwort
3 smtp.ionos.de otto@example.com:ottos_passwort
Das funktioniert???? Nur wo kommen jetzt hugo, otto und paul ins spiel?
Na in Zeile 2, 3 und 4 Deiner sasl_passwd1 smtp.ionos.de postbote@example.com:postbotes_passwort
2 smtp.ionos.de hugo@example.com:hugos_passwort
3 smtp.ionos.de otto@example.com:ottos_passwort
Du glaubst doch nicht, dass ich so eine Konstellation mal irgendwo in irgenddeinem HowTo gesehen habe...
Und ich habe zig Howtos gelesen bevor ich den Server aufgesetzt habe.
Das kann ich aber mal hausintern gefahrlos testen.
und nach dem Editieren immer schön ans postmap denken
und service postfix restart
Gruß
Frank
Das funktioniert???? face-surprise face-surprise
Ist bei mir sehr lange her, ich betreibe meine Server nur noch direkt. Aber ich erinnere mich - und hier steht:
Viele Grüße, commodity
Edit: Ist auch nicht so, dass das noch niemand gemacht hätte
https://gist.github.com/zmwangx/2c56aa32be68daf48c2f?permalink_comment_i ...
Ist bei mir sehr lange her, ich betreibe meine Server nur noch direkt. Aber ich erinnere mich - und hier steht:
smtp_sasl_password_maps (default: empty)
Optional Postfix SMTP client lookup tables with one username:password entry per sender, remote hostname or next-hop domain.
Wichtig aber auch:Optional Postfix SMTP client lookup tables with one username:password entry per sender, remote hostname or next-hop domain.
Per-sender lookup is done only when sender-dependent authentication is enabled.
Viele Grüße, commodity
Edit: Ist auch nicht so, dass das noch niemand gemacht hätte
https://gist.github.com/zmwangx/2c56aa32be68daf48c2f?permalink_comment_i ...
1
Moin
Also nein, so wie Du das beschrieben hast geht es nicht aber es war dicht dran.
Die 'Edit' hat das sehr gut erklärt:
Lösung: https://gist.github.com/zmwangx/2c56aa32be68daf48c2f?permalink_comment_i ...
Insofern erspare ich es mir, das ganze nochmal aufzubereiten.
Hab es auch schon ins Livesystem ausgerollt.
Das Schöne daran ist, man muss die Accounts nicht alle auf einmal umstellen sondern man kann das bis zum 15.1. nach und nach tun.
Insofern das wichtigste wird am 15.1. laufen.
Einen Pferdefuß gibt es noch.
In iRedMail ist u.a. die Groupware SOGo enthalten, die wir auch nutzen.
Mailweiterleitungen scheint das Ding mit der originären Absender-Adresse zu machen. Wenn mir also Amazon eine Mail schickt und ich die auf eine externe Mailadresse weiterleite dann versendet SOGo die auch mit dem From 'Amazon'.
Zu prüfen ist noch wie das mit Terminen und Abwesenheitsbenachrichtigungen ist.
Also weitersuchen. Damit es auch nicht langweilig wird.
Dank Dir @commodity für die Hilfe *thumps-up*
Gruß
Frank
Also nein, so wie Du das beschrieben hast geht es nicht aber es war dicht dran.
Die 'Edit' hat das sehr gut erklärt:
Lösung: https://gist.github.com/zmwangx/2c56aa32be68daf48c2f?permalink_comment_i ...
Insofern erspare ich es mir, das ganze nochmal aufzubereiten.
Hab es auch schon ins Livesystem ausgerollt.
Das Schöne daran ist, man muss die Accounts nicht alle auf einmal umstellen sondern man kann das bis zum 15.1. nach und nach tun.
Insofern das wichtigste wird am 15.1. laufen.
Einen Pferdefuß gibt es noch.
In iRedMail ist u.a. die Groupware SOGo enthalten, die wir auch nutzen.
Mailweiterleitungen scheint das Ding mit der originären Absender-Adresse zu machen. Wenn mir also Amazon eine Mail schickt und ich die auf eine externe Mailadresse weiterleite dann versendet SOGo die auch mit dem From 'Amazon'.
Zu prüfen ist noch wie das mit Terminen und Abwesenheitsbenachrichtigungen ist.
Also weitersuchen. Damit es auch nicht langweilig wird.
Dank Dir @commodity für die Hilfe *thumps-up*
Gruß
Frank
Gerne, danke für's Feedback.
Das Thema kommt bestimmt auf einige zu.
Viele Grüße, commodity
Das Thema kommt bestimmt auf einige zu.
Viele Grüße, commodity
Abbend.
Inzwischen scheint IONOS entweder zurückgerudert zu haben oder deren Planung konkretisiert zu haben:
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/wichtige-aenderung-f ...
Demnach hätte ich mir den Stress sparen können.
Relaying über genau ein Ausgangs-Postfach soll wohl weiter funktionieren wenn die Absender-Domain zur Relay-Account-Domain gehört. Mein Postbote muss also nicht in Rente.
'Lediglich' die serverseitige Mailweiterleitung nach Extern wird dann wohl nicht mehr funktionieren.
Viele Grüße
Frank
Inzwischen scheint IONOS entweder zurückgerudert zu haben oder deren Planung konkretisiert zu haben:
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/wichtige-aenderung-f ...
Demnach hätte ich mir den Stress sparen können.
Relaying über genau ein Ausgangs-Postfach soll wohl weiter funktionieren wenn die Absender-Domain zur Relay-Account-Domain gehört. Mein Postbote muss also nicht in Rente.
'Lediglich' die serverseitige Mailweiterleitung nach Extern wird dann wohl nicht mehr funktionieren.
Viele Grüße
Frank
