separate Mail- und Webhosting-Server mit mehreren Domänen; Spam-Vermeidung, PTR- und SPF-Einträge

Question

Kontext.

Ich habe mehrere Domain-Webdienste, die auf einem Digital Ocean Droplet gehostet werden (Ubuntu und Nginx im Stack). Anscheinend richtet DO automatisch einen PTR-Eintrag ein. Wenn ich jedoch abfrage

host <IP_ADDRESS>
[...] not found: 3(NXDOMAIN)

Das Droplet verwendet Postfix, konfiguriert als where inet_interfaces = all inet_protocols=ipv4und mydestinationenthält die gehosteten Webservice-Domänen (mit und ohne www-Präfix). Diese Domänen versenden E-Mails über sendmailund einen Host, definiert alsscheduler.sending.ws

DNS- und Mail-Dienste werden über einen zweiten Anbieter ausgeführt (der NICHT der Registrar für die Second-Level-Domain ist). Mir ist zunächst aufgefallen, dass ein A-Eintrag auf die richtige IP-Adresse verweist, allerdings mit einem Tippfehler. schedule.sending.wsDas kann behoben werden, obwohl ich nicht sicher bin, ob das wirklich relevant ist.

Der MX-Eintrag verweist ordnungsgemäß auf den zweiten Anbieter. mail.sending.ws Es gibt außerdem zwei TXT-Einträge für @und , admindie auf verweisen v=spf1 a mx ptr include:someserver.net ~all.

Dies führt dazu, dass E-Mails mit folgendem Header generiert werden mit einemzufälligDomäne, definiert in mydestinationder Postfix-Datei main.cf:

Received: from www.other.ws ([IP_ADDRESS]:46818)

Es handelt sich also um zwei unterschiedliche Ausgabereferenzen, eine Situation, die leicht zu einer Kennzeichnung als Spam führen kann.

bitte entschuldigen Sie meine völlige Verwirrung und den Verstoß gegen das Protokoll, mehrere Fragen zu stellen
Meine derzeitige Annahme ist, dass:
a) ein neuer TXT-DNS-Eintrag für die ausstellende Domäne gesetzt werden muss, wie: v=spf1 a mx include:scheduler.sending.ws include:someserver.net ~all?
b) wenn a) richtig ist, muss natürlich der A-Eintrag korrigiert werden
c) die Nichtübereinstimmung in den Headern muss noch behoben werden. Dies muss jedoch auf jeden Fall von der Anwendung (und damit der spezifischen Domäne) angegeben werden, die die E-Mail mit einer der von Postfix definierten Domänen vorbereitet ... wird Postfix mitspielen?

fehlen Daten, um dieses Problem richtig anzugehen?

Answer 1

Insgesamt sollten Sie wirklich einige Tutorials befolgen, um eine funktionierende Grundkonfiguration zu erstellen, anstatt zufällige Konfigurationen auszuprobieren, ohne zu wissen, wie E-Mails funktionieren. Schließlich ist die Verwaltung eines E-Mail-Systems heutzutage eine komplizierte und anspruchsvolle Aufgabe. Für alle ohne umfassende Erfahrung und mit besonderen Anforderungen an einen eigenen E-Mail-Server empfiehlt sich die Verwendung eines externen Dienstes, der über alle erforderlichen Spam-Abwehrsysteme und standardmäßigen Absender-Reputationsmanagementsysteme verfügt.

Um Ihre einzelnen Fragen zu beantworten und Anleitungen zum Erlernen der dahinter stehenden Technologien zu geben. Lassen Sie uns in dieser Antwort www.example.com. A 192.0.2.1als Webserver und mail.example.com. A 192.0.2.2als Mailserver für eingehende E-Mails verwenden. Beide müssen E-Mails senden, aber nur mail.example.comempfangen, richtig?

• a) Nein. Der SPFincludeMechanismusist nicht für diesen Zweck. include:scheduler.example.combedeutet, dass weitere Regeln, d. h. andere SPF-Einträge, vorhanden sind scheduler.example.com. TXT. Da es wahrscheinlich keinen solchen Eintrag gibt, würde dies einen PermError verursachen, der möglicherweise zur Ablehnung der Nachricht führt.

  Der SPF-Eintrag sollte alle Server zulassen, die E-Mails für den entsprechenden Hostnamen senden. Wenn Sie verwenden example.com, haben Sie es auf example.com. TXT, für www.example.com.auf www.example.com. TXT. Es wird empfohlen, denip4Undip6Mechanismen, wann immer möglich, da dadurch weniger DNS-Abfragen bei der Überprüfung auf SPF erforderlich sind. Dies hätte zur Folge:

  example.com.      IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  www.example.com.  IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  

• b) Bei eingehender Postzustellung scheduler.example.com. Aist es unerheblich, es sei denn, sie wurde alsMail-AustauscherzB example.com. MX scheduler.example.com., aber wahrscheinlich gibt es nur, mail.example.com.wenn Sie es als HELOHostnamen verwenden, sollten Sie den AEintrag haben, um zu vermeidenSMTP-Banner stimmt nicht überein.

• c) Der HELOHostname stimmt mit dem Postfix-Konfigurationsparameter übereinsmtpd_banner. Standardmäßig hat es diemyhostnameals Variable ist ie dasselbe, das Sie als haben myhostname. Das mydestinationhat damit nichts zu tun, und nichts wählt einen zufälligen Hostnamen aus dieser Einstellung: Es dient zum Zustellen von E-Mails, nicht zum Senden.

  Der HELOHostname muss einen übereinstimmenden AEintrag haben und sollte mit dem der IP-Adresse identisch sein PTR. Er muss nicht mit dem übereinstimmenUmschlag AbsenderDomäne noch die From:Header-Adresse. In einem E-Mail-Server mit mehreren Domänen wäre das auch unmöglich.

Bei Problemen mit der Funktionsfähigkeit von Maildomänen wird empfohlen, die tatsächliche Domäne zu verwenden, damit wir prüfen können, was los ist. Diese Frage ist weit gefasst und unbestimmt: Es ist unmöglich, eine genaue oder allgemeine Antwort zu geben.