Office 365 - PRT

[Alith Anar 40]

Hallo,

 

ich steh gerade ganz schön auf dem Schlauch.

 

Eine Kunde von mir setzt Office 365 ein und betreibt zusätzlich einen Webserver auf einer anderen IP.

Die Domain ist bei der Swisscom gehostet.

Bis auf den SIP Eintrag sind alle notwendigen DNS Einträge hinterlegt und werden auch vom O365 Portal als OK eingestuft.

 

Der Mailversand läuft fast super, den wenn der Kunde einem Mail an einen bestimmten Partner versenden möchte erhält er folgende Nachricht:

 

Weitere Informationen für E-Mail-Administratoren

Statuscode: 550 5.7.364 

Offenbar hat der E-Mail-Server des Empfängers unter <empfänger-domain> eine rDNS-Suche (Reverse DNS) als Sicherheitsüberprüfung ausgeführt, um zu überprüfen, ob die IP-Absenderadresse der Absenderdomäne zugeordnet ist, und bei der Suche ist ein Fehler aufgetreten. Offenbar ist der PTR-Eintrag (Pointer) für blindenheimbasel.ch nicht ordnungsgemäß eingerichtet.

Richten Sie den PTR-Eintrag Ihrer Domäne ein, oder korrigieren Sie ihn – Wenn Sie der Administrator von <Absenderdomain> sind, arbeiten Sie mit Ihrem DNS-Hostinganbieter (Ihrer Domänenregistrierungsstelle, dem Webhostinganbieter oder dem ISP) zusammen, um einen PTR-Eintrag für Ihre Domäne ordnungsgemäß einzurichten. Wenn Sie Office 365 verwenden, um Ihre DNS-Einträge zu verwalten, beachten Sie, dass die Erstellung und Verwaltung von PTR-Einträgen in Office 365 nicht unterstützt wird, sodass Sie Ihre DNS-Verwaltung auf einen DNS-Host außerhalb von Office 365 umstellen müssen. Anweisungen, wie Sie dies erreichen können, finden Sie in diesem Artikel: Ändern der Verwaltungsart von DNS-Einträgen mit Office 365.

Leider kann Ihnen der Office 365-Support bei der Behebung dieser Art extern gemeldeter Fehler nicht helfen, weil Office 365 die Verwaltung von PTR-Einträgen nicht unterstützt.

 

 

Fehlerdetails Gemeldeter Fehler: 550 5.7.364 Remote server returned invalid or missing PTR (reverse DNS) record for sending domain -> 554 5.7.1 Spamassassin-Score: 5.104 >= 5 : Content indicates spam: DKIM_SIGNED,EXTRA_MPART_TYPE,GIF_IMAGE_EXTRA_4,HTML_MESSAGE,ONE_PICTURE,RDNS_NONE,SHORT_HELO_AND_INLINE_IMAGE,SMILEY,SPF_HELO_PASS,SPF_PASS,URIBL_SC_SWINOG  Anzahl der Wiederholungen: 1  DSN generiert von: DB5PR04MB1510.eurprd04.prod.outlook.com Remoteserver: mx.<Remoteserver>

 

Die Im Link aufgeführte Anleitung seitens MS besagt das ich die DNS Server im O365 anpassen muss. Wo finde ich aber dieses Option? Ich habe keine Möglichkeit die NS Server zu ändern. Oder wie bekomme ich den PTR Eintrag hin?

 

Vielen Dank

Thomas

[zahni 554]

Ich  würde es mal mit  einem SPF versuchen. Bei Office 365 bekommt man sicher keine eigene feste IP-Adresse.  Daher  kannst Du auch keinen PTR setzen:

 

https://technet.microsoft.com/de-de/library/dn789058(v=exchg.150).aspx

[Alith Anar 40]

SPF ist gesetzt (und auch schon seit ein paar Monaten gesetzt)
 

TXT

-

@

v=spf1 include:spf.protection.outlook.com -all

 

Der Fehler ist trotzdem da. :(

bearbeitet 28. September 2016 von Alith Anar

[djmaker 95]

Der PRT wird immer vom Betreiber der öffentlichen IP (hinter der der Exchange-Server liegt) gesetzt.

[Alith Anar 40]

Ja, aber Office 365 unterstützt keinen PRT. In sofern ist meine Frage: Wie bekomme ich die Mail durch den SPAMFilter bei Spamassassin der einen PRT haben will. ?

[NorbertFe 2.035]

Dann frag doch den filternden Empfänger, ob er da mal an seinem Assassin drehen kann/will. Übrigens heißt das Ding PTR für Pointer. ;) Ich tippe mal auf eine fehlerhafte Prüfung beim Empfänger, der zwingend einen Reverse Eintrag aus der Sendedomain haben will und das ist eben 1. oft nicht möglich und 2. auch gar nirgends per RFC gefordert.

bearbeitet 28. September 2016 von NorbertFe

[PowerShellAdmin 169]

das ist eben 1. oft nicht möglich und 2. auch gar nirgends per RFC gefordert.

Umgekehrt richtet man es aber immer ein, da es einen Fallstrick darstellt.

Eben weil es üblich ist, ganz unabhängig davon dass es nicht klar gefordert ist, nun mal ein schwebender Standard.

 

Ebenso hilft es einen nicht weiter, wenn diverse Empfänger nicht erreichbar sind, was offiziell vor einigen Jahren verabschiedet wurde.

[NorbertFe 2.035]

Man muß einen PTR haben, aber der muß eben NICHT mit der Absendedomain assoziiert sein. Was bei Providern oftmals ja auch gar nicht möglich ist. Siehe oben. ;)

[PowerShellAdmin 169]

Man muß einen PTR haben, aber der muß eben NICHT mit der Absendedomain assoziiert sein. Was bei Providern oftmals ja auch gar nicht möglich ist. Siehe oben. ;)

Ah alles klar - dann habe ich das falsch verstanden ;) Asche über mein Haupt.

[magheinz 110]

Dann frag doch den filternden Empfänger, ob er da mal an seinem Assassin drehen kann/will. Übrigens heißt das Ding PTR für Pointer. ;) Ich tippe mal auf eine fehlerhafte Prüfung beim Empfänger, der zwingend einen Reverse Eintrag aus der Sendedomain haben will und das ist eben 1. oft nicht möglich und 2. auch gar nirgends per RFC gefordert.

Zum RFC und den PTR. Zu checken ob der Server in der gleichen Domaine wie der From-Header ist ergibt wenig Sinn. Das wird schon klar wenn amn bedenkt das man ja durchaus mehrere Domänen unter einer IP betreiben kann. Zu überprüfen ob der PTR mit dem A-Record matcht ist sehr sinnvoll. Damit filtert man schon ziemlich viel raus und das macht auch so gut wie jeder E-Mailserver. Kannst ja mal versuchen bei web.de was einzuliefern wenn das nicht zusammenpasst.

 

http://www.faqs.org/rfcs/rfc1912.html

2.1 Inconsistent, Missing, or Bad Data

[...]

Make sure your PTR and A records match. For every IP address, there

should be a matching PTR record in the in-addr.arpa domain. If a

host is multi-homed, (more than one IP address) make sure that all IP

addresses have a corresponding PTR record (not just the first one).

Failure to have matching PTR and A records can cause loss of Internet

services similar to not being registered in the DNS at all. Also,

PTR records must point back to a valid A record, not a alias defined

by a CNAME.[...]

 

und wegen dem "should":

Macht man's nicht braucht man einen guten Grund(RFC2119).

3. 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.

 

Welcher sollte das sein?

 

Also:

1. Überprüfen auf welche IP der A-Record des Mailservers auflöst

2. Überprüfen ob die IP auf den gleichen Namen auflöst.

Wenn ja: Fehler beim Empfangsserver. Der checkt dann wohl wirklich irgend etwas unsinniges.

Wenn nein: Fehler beim Absender. Hier läuft DNS dann quer.

 

abgesehen davon: Die E-Mail ist ja aus noch mehr Gründen als Spam erkannt worden:

DKIM_SIGNED

EXTRA_MPART_TYPE

GIF_IMAGE_EXTRA_4

HTML_MESSAGE

ONE_PICTURE

RDNS_NONE

SHORT_HELO_AND_INLINE_IMAGE

SMILEY

SPF_HELO_PASS

SPF_PASS

URIBL_SC_SWINOG

 

Die meisten dieser Regeln dürften den score vergrößert haben. Allerdings ab einem score von 5 die Mail als spam zu erkennen ist auch etwas mutig.

[NorbertFe 2.035]

Ähm ja, schon länger her, aber wo hab ich behauptet, dass Reverse und forward nicht passen müssten?

[magheinz 110]

Ich wolle dir nicht widersprechen sondern deine Aussage mit den entsprechenden RFCs untermauern.

[NorbertFe 2.035]

Achsooo :)