
Ich wollte wissen, ob das Format des PTR-Eintrags die Reputation des Mailservers beeinflusst, zum Beispiel: -
Beispiel:-1
dig -X 162.254.148.198 (this ip belongs to mail.setopati.com)
;; ANSWER SECTION:
198.148.254.162.in-addr.arpa. 21577 IN PTR 162-254-148-198.static.hvvc.us.
Beispiel:-2 (dieses hypothetische Beispiel)
dig -X 162.254.148.198
;; ANSWER SECTION:
198.148.254.162.in-addr.arpa. 21577 IN PTR 162-254-148-198.mail.setopati.com.
hier sind einige Googlemail-Reverse-Records, aber die Antwort stimmt nicht mit etwas wie „mail.google.com“ überein dig -x 216.58.220.37
;; ANSWER SECTION:
37.220.58.216.in-addr.arpa. 21599 IN PTR maa03s18-in-f37.1e100.net.
37.220.58.216.in-addr.arpa. 21599 IN PTR maa03s18-in-f37.1e100.net.
37.220.58.216.in-addr.arpa. 21599 IN PTR maa03s18-in-f5.1e100.net.
Antwort1
Es gibt sagen wir mal 4 Faktoren... der einzige direkte Nachteil für die Reputation ist Dynamic PTR von IPv4 und FCrDNS für IPv6
Dynamischer vs. statischer PTR: Wenn Sie einen statischen PTR haben, der besser ist als ein dynamischer, erhalten Sie einige Pluspunkte auf Systemen wieSpam-Attentäteroder RBLs wie RFC-Ignorant.
FCrDNS, nützlich für Dinge wie Opportunistic TLS, Protokolle, Netflows usw.
mail.example.com. IN A 162.254.148.198 198.148.254.162.in-addr.arpa. 21599 IN PTR mail.example.com.
Was ist mit SPF? Verwenden Sie PTR in Ihrem SPF-Eintrag? Wenn ja, TUN SIE ES NICHT.
5.5. „ptr“ (nicht verwenden)
Dieser Mechanismus prüft, ob das DNS-Reverse-Mapping existiert und korrekt auf einen Domänennamen innerhalb einer bestimmten Domäne verweist. Dieser Mechanismus SOLLTE NICHT veröffentlicht werden. Weitere Informationen finden Sie im Hinweis am Ende dieses Abschnitts. -RFC7208 Abschnitt 5.5
- IPv6!!!! Das hat jetzt noch niemand für E-Mail erwähnt, für IPv6 müssen Sie FCrDNS haben.
Die sendende IP muss einen PTR-Eintrag haben (also einen Reverse-DNS der sendenden IP) und sie sollte mit der IP übereinstimmen, die über die Forward-DNS-Auflösung des im PTR-Eintrag angegebenen Hostnamens erhalten wurde. Andernfalls wird die E-Mail als Spam markiert oder möglicherweise abgelehnt. -Google.com
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1h IN PTR mail.example.com.
mail.example.com. IN AAA 2001:db8::1
Antwort2
Ich wiederhole meine obige Behauptung: dass es niemanden (*) interessiert, welches Textformat eine PTR
Datensatzzeichenfolge hat.
Was sieTunoft kümmern ist, dass SiehabenEin PTR
Datensatz, der mit der IP-Adresse Ihres Servers verknüpft ist. Jeder PTR
Datensatz, den Sie für diese Adresse zurückgeben, kann aufgelöst werden, um einen A
Datensatz zurückzugeben, der auf die ursprüngliche IP-Adresse verweist.
(*) Eigentlich kann es jeden interessieren. Es ist Sache des Mailserver-Administrators, auf welchen Faktoren er seine Entscheidung über Annahme/Ablehnung/Falschablage für jede eingehende E-Mail basiert, und ich nehme an, er könnte entscheiden, dass PTR
Datensätze, die beispielsweise keine Blumennamen enthalten, ein Zeichen für einen ungültigen Absender sind. Sie könnten nichts gegen eine solche Entscheidung tun, wenn sie getroffen würde, aber es wäre eine ungewöhnliche Entscheidung (gelinde gesagt) und würde in der Community wenig Unterstützung finden, wenn der Server-Administrator aufgefordert würde, sie den Eigentümern des Servers gegenüber zu rechtfertigen. Dasselbe gilt meiner Erfahrung nach für Beschränkungen des Textformats eines PTR
Datensatzes.
Antwort3
Die Reputation eines Mailservers ist kein Standard (es gibt jedoch RFCs wieRFC7073 die auf eine Standardisierung abzielen, aber den PTR-Eintrag nicht einmal erwähnen)
Daher ist es nicht möglich, diese Frage zu beantworten, da jedes Spam-Schutzsystem über eigene Regeln zur Bewertung der Reputation eines Mailsystems verfügt.
Wie MadHatter sagte, ist das einzig „Offizielle“, dass der vom Reverse Lookup zurückgegebene Datensatz die ursprüngliche IP auflösen muss.