Postfix Konfigurationsdateien bearbeiten

H

Hausherr

New Member
Kann ich bei Verwendung von Plesk die Postfix Konfigurationsdateien einfach bearbeiten oder muss ich damit rechnen, dass mir Plesk alles wieder überschreibt?

Ich würde gerne unterbinden, dass Postfix DSN-Meldungen an externe versendet, wie auch die IP Adresse des Senders mit im Mail Header auftaucht und der Mail-Agent.
 
Das ist keine Vorschrift, wenn dann Empfehlung/Anregung (Requests for Comments). Ich werde trotzdem nicht meine IP und damit den Standort dem Empfänger offen legen.

Die Ausgangsfrage war aber auch, ob die Konfigurationsdateien von Postfix durch den Einsatz von Plesk überschrieben werden oder ob die Modifikationen technisch bestehen bleiben.
 
Hausherr said:
Das ist keine Vorschrift, wenn dann Empfehlung/Anregung (Requests for Comments). Ich werde trotzdem nicht meine IP und damit den Standort dem Empfänger offen legen.
Click to expand...
Das ist so nicht richtig. Lies doch bitte einmal https://de.wikipedia.org/wiki/Request_for_Comments
Hausherr said:
Die Ausgangsfrage war aber auch, ob die Konfigurationsdateien von Postfix durch den Einsatz von Plesk überschrieben werden oder ob die Modifikationen technisch bestehen bleiben.
Click to expand...
Findest u.a. hier: https://support.plesk.com/hc/en-us/...n-cf-and-etc-postfix-master-cf-gets-reverted-
 
Hausherr said:
Ich werde trotzdem nicht meine IP und damit den Standort dem Empfänger offen legen.
Click to expand...
Dann wirst Du nicht viele Empfänger erreichen, denn das Fehlen Deiner IP ist ein Bruch des vorgeschriebenen Internetstandards und damit ein gravierender Ablehnungsgrund...
 
Joe User said:
Dann wirst Du nicht viele Empfänger erreichen, denn das Fehlen Deiner IP ist ein Bruch des vorgeschriebenen Internetstandards und damit ein gravierender Ablehnungsgrund...
Click to expand...

Ich bin mir sicher, er meint, die IP-Adresse des einliefernden Clients zu maskieren, resp. nicht in den Received-Header aufzunehmen.
Das verstößt nicht gegen RFCs, die lediglich sagen, dass es drin stehen sollte um Debugging zu verbessern. Sie schreiben explizit "SHOULD" und nicht "MUST".
Mache ich im übrigen auf den von mir betriebenen Gateways auf den Submission-/SMTPS-Ports auch, wo die Clients einliefern. Deren IP-Adresse und Hostname werden schlicht nicht in den vom Server erzeugten Received-Header geschrieben, stattdessen wird "localhost" dort eingesetzt, damit das syntaktisch in Ordnung bleibt.
Bisher kommen alle E-Mails an (mehrere Tausend pro Tag) und ich bin ja auch weißgott nicht der einzige, der das so handhabt...
 
Ja, RFC 5321 3.7.2. und RFC 5321 4.4. sprechen von "SHOULD", was in RFC 2119 3. wie folgt definiert ist:
SHOULD
This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Click to expand...
Und genau das zweifel ich (nicht nur) bei dem TE/OP stark an, womit er eindeutig gegen den RFC 5321 verstösst.


BTW: Was macht Ihr denn mit bereits vorhandenen Received-Zeilen aus dem Netzwerk des Einliefernden?
 
Joe User said:
BTW: Was macht Ihr denn mit bereits vorhandenen Received-Zeilen aus dem Netzwerk des Einliefernden?
Click to expand...

Die werden gelassen wie sie sind.
Einzig der von unserem Mailserver erzeugte Received-Header enthält eben nicht die IP-Adresse des einliefernden Clients.
Andere Informationen wie Queue-ID u.s.w. bleiben erhalten, so dass man auch problemlos von beiden Seiten aus debuggen kann.
 
Cool, dann weiss ich beim Debuggen also nicht, wem das Netzwerk hinter Deinem Mailserver gehört? Das hilft natürlich ungemein beim Debuggen...


Man stelle sich mal vor, es würde jeder einzelne Mailserver seinen Received-from auf localhost/127.0.0.1/::1 manipulieren, dann könnte Niemand mehr vernünftig Debuggen, da man erstmal jeden einzelnen Postmaster im Path rückwärts anschreiben müsste, um ihn zu bitten, doch mal in seine Logs zu schauen, ob und wann ja wer am 20.04.2022 um 00:47 MESZ eine Mail an foo@bar.local eingeliefert hat. Natürlich wird jeder dieser Postmaster in einer Debug-tauglichen Zeitspanne eine Debug-taugliche Antwort liefern und dabei mal eben gegen eventuell für ihn geltendes Recht verschstossen.

Sorry, dagegen setze ich jede Summe und werde garantiert diese Wette nicht verlieren...
 
Sagen wir es so: Wenn du eine Mail erhalten hast, aus der du die Received-Header zauberst - was genau willst du dann im Remote-Netzwerk debuggen?
Du hast Uhrzeiten und du hast die Angabe, an welcher Stelle eine E-Mail per SMTPA eingeliefert wurde (also was der Client ist).

Es gibt ja eigentlich ohnehin nur zwei mögliche Szenarien, wo du debuggen musst:
1) Du bekommst E-Mails nicht und willst rausfinden, warum nicht. Dann hast du sowieso nur deine eigenen Logs, den Absender als Ansprechpartner, aber in jedem Fall keine Received-Header.
2) Du bekommst E-Mails und willst wissen, wo sie herkommen oder warum sie z.B. verspätet sind.
Die Zeiten bleiben intakt, daran kannst du erkennen wo Mails ggf. festhingen. Und du hast wie gesagt die Protokollinfo, an welcher Stelle der Kunde das per SMTPA eingeliefert hat.

In beiden Fällen hilft dir nicht, die IP-Adresse des einliefernden Client (in mindestens 99% der Fälle bei uns ein MUA) zu wissen.
Denn entweder hing die E-Mail auf unserem Server fest, dann wendest du dich eh an uns. Oder sie hing beim Kunden. Dann musst du ohnehin den Kunden kontaktieren, um da nachforschen zu lassen.
Die (dynamische) IP-Adresse des Internetzugangs zu sehen, von wo aus der MUA die Mail eingekippt hat, ist da an keiner Stelle ein ernstzunehmender Mehrwert.
 
Du vergisst Spam und da sind Received-from = localhost/127.0.0.1/::1 durchaus ein Indikator für kaputte Mailsysteme, welche von manchen Anbietern per automatisiertem Debugging erstmal pauschal auf interne und teilweise gar externe Blacklists gesetzt werden. Glücklicherweise sind es nicht viele, aber durchaus "wichtige" aka Konzerne, Behörden, Organisationen und auch mindestens zwei grössere Mailprovider (Südamerika und Asien).
Und ich möchte durchaus ohne Nachfragen wissen, ob nun Dein Mailserver ein Problem hat, oder das bei Dir einliefernde Netzwerk, oder ob die ersten Received einfach nur vom Spammer erfunden wurden und innerhalb wessen Netzwerk der Spammer die gefakten Received eingefügt hat. Das geht aber nur, wenn ich den Path eindeutig nachverfolgen kann und das geht nur bis zu dem letzten Host der vollständige und korrekte Received gesetzt hat. Bei Dir müsste ich dann also erstmal nachfragen und hoffen, dass Du mir antwortest und das Ganze müsste dann auch noch innerhalb der Löschfristen passieren. Alternativ setze ich halt Dich auf diverse Blacklists, viel Spass damit...

Die Einschränkung "but the full implications must be understood and carefully weighed before choosing a different course" steht nicht grundlos im RFC 2119. Für Fälle wo das nicht erforderlich ist, verwenden RFC den Terminus "MAY"...
 
You must log in or register to reply here.
Back
Top