Header Bearbeitung durch Exchange

[Lukikum 6]

Hallo zusammen,

 

ich habe mitgeteilt bekommen, dass Exchange Server gerne mal Header Zeilen löschen. Ich habe von unserem Smarthost aber eine Regelung einführen lassen, die eine Header Zeile hinzufügt, sobald ein SPF_Fail stattfindet (Grund dafür ist eine Markierung von gefälschten Adressen). Diese Headerzeile konnte ich aber nicht in einer Testmail finden.

Gibt es eine Möglichkeit zu überprüfen welche Header Zeilen der Exchange entfernt? Smarthost Anbieter meint zumindest dass die Regel richtig konifguriert ist. Also denke ich dass das Problem dort liegen könnte.

LG
Lukas

[mikro 58]

Moin hast du im OWA oder Postfach Emailweiterleitungsregeln? Die erzeugen eine neue Mail und zeigen somit nicht mehr den ursprünglichen Header an.

 

mikro

[cj_berlin 1.138]

Moin,

 

ein häufiger Kritikpunkt am Exchange ist, dass er zu viele Informationen dem Header bei Versand hinzufügt. Dass er beim Empfang etwas entfernen würde (ohne dass dies in einer Transportregel gefordert wird), ist mir neu. Wenn die hinzugefügte Zeile allerdings nicht RFC-konform ist, könnte es schon sein, dass sie verworfen wird.

[NorbertFe 1.805]

vor 30 Minuten schrieb Lukikum:

ich habe mitgeteilt bekommen, dass Exchange Server gerne mal Header Zeilen löschen.

Und die Behauptung steht jetzt mal einfach so im Raum. ;) gibts da auch Beispiele oder Belege?

 

vor 31 Minuten schrieb Lukikum:

Gibt es eine Möglichkeit zu überprüfen welche Header Zeilen der Exchange entfernt?

Nennt sich pipeline tracing.

vor 32 Minuten schrieb Lukikum:

Ich habe von unserem Smarthost aber eine Regelung einführen lassen, die eine Header Zeile hinzufügt, sobald ein SPF_Fail stattfindet (Grund dafür ist eine Markierung von gefälschten Adressen).

Warum nimmst du die überhaupt an? Bei spf fail hat doch der Absender klar definiert was er erwartet, was mit gefälschten Mails passieren soll. (Zumindest wenn er weiß was er tut)

[Lukikum 6]

vor 1 Stunde schrieb mikro:

Moin hast du im OWA oder Postfach Emailweiterleitungsregeln? Die erzeugen eine neue Mail und zeigen somit nicht mehr den ursprünglichen Header an.

 

mikro

Ne eine Weiterleitung wird es nicht sein

vor 1 Stunde schrieb cj_berlin:

Moin,

 

ein häufiger Kritikpunkt am Exchange ist, dass er zu viele Informationen dem Header bei Versand hinzufügt. Dass er beim Empfang etwas entfernen würde (ohne dass dies in einer Transportregel gefordert wird), ist mir neu. Wenn die hinzugefügte Zeile allerdings nicht RFC-konform ist, könnte es schon sein, dass sie verworfen wird.

Mhh unser Smarthost fügt so einige Header hinzu, würde mich wundern wenn der neue aufeinmal nicht konform sein sollte. Wenn es anscheinend doch nicht so üblich ist, dass Exchange gerne mal Header Zeilen verwirft, könnte es doch am Smarthost Anbieter liegen.

vor einer Stunde schrieb NorbertFe:

Und die Behauptung steht jetzt mal einfach so im Raum. ;) gibts da auch Beispiele oder Belege?

Nicht wirklich, das ist die Aussage die ich bekommen habe "MS-Exchange-Server löschen (je nach Einstellung) Header-Zeilen. Das ist kein Bug, sondern so beabsichtigt, insbesondere, wenn Exchange-Cluster betrieben werden und die Zwischenstationen dort nicht alle abgebildet werden sollen. Dort kann natürlich auch die Header-Zeile "X-HZI-spffail: Yes" zum Opfer fallen. "

Als Beispiel meinte er, dass ein Header der von deren Server erstellt wird, immer von unseren Exchange entfernt wird. Hab jetzt keinen Grund gesehen ihm nicht zu vertrauen da er schon einiges an Erfahrung hat und mit vielen verschieden SMTP Serversystemen arbeitet.

vor einer Stunde schrieb NorbertFe:

Nennt sich pipeline tracing.

Danke, ich werde mich darüber mal einlesen und schauen was sich dabei ergibt :)

 

vor einer Stunde schrieb NorbertFe:

Warum nimmst du die überhaupt an? Bei spf fail hat doch der Absender klar definiert was er erwartet, was mit gefälschten Mails passieren soll. (Zumindest wenn er weiß was er tut)

Ich habe die Konfiguration so von meinem Vorgänger übernommen. Die Mails werden bei einem SPF_Fail mit einem Spamscore versehen, zusätzlich sollen sie jetzt aber auch noch markiert werden. Der Grund warum wir die nicht ablehnen, ist vermutlich durch zu viele false positive, da nicht jeder Geschäftspartner SPF Records veröffentlicht hat. Bei unserem Fachbereich arbeiten wir viel mit kleineren Nischenunternehmen zusammen. Kann aber auch sein dass sich in dem Bereich noch nicht genug gedanken gemacht wurden, muss ich noch überprüfen. Es gibt halt einiges was ich aufarbeiten muss :P

Gruß
Lukas

[testperson 1.534]

Hi,

 

geht es tatsächlich nur um SPF Fail? Dann siehe @NorbertFes Antwort -> Und weg damit.

 

Gruß

Jan

[NorbertFe 1.805]

vor einer Stunde schrieb Lukikum:

Nicht wirklich, das ist die Aussage die ich bekommen habe "MS-Exchange-Server löschen (je nach Einstellung) Header-Zeilen. Das ist kein Bug, sondern so beabsichtigt,

Je nach Einstellung ist das also beabsichtigt? Hmm. Also so pauschal würd ich das ohne Beleg erstmal in Frage stellen. DIe Mails werden euch per SMTP zugestellt nehme ich an?

 

vor einer Stunde schrieb Lukikum:

Der Grund warum wir die nicht ablehnen, ist vermutlich durch zu viele false positive, da nicht jeder Geschäftspartner SPF Records veröffentlicht hat.

Wenn nicht jeder Geschäftspartner SPF Records veröffentlicht hat, haben die ohne SPF Records ja auch keine Probleme mit SPF Records. ;) (Dafür dann halt andere).

[Lukikum 6]

vor 15 Stunden schrieb NorbertFe:

Je nach Einstellung ist das also beabsichtigt? Hmm. Also so pauschal würd ich das ohne Beleg erstmal in Frage stellen. DIe Mails werden euch per SMTP zugestellt nehme ich an?

Ja die Mails werden per SMTP zugestellt. Zuerst werden sie an einen HAproxy geleitet und dann von dort zu unserem Servercluster.

 

vor 15 Stunden schrieb NorbertFe:

Wenn nicht jeder Geschäftspartner SPF Records veröffentlicht hat, haben die ohne SPF Records ja auch keine Probleme mit SPF Records. ;) (Dafür dann halt andere).

Mh das stimmt, ich müsste mal in Erfahrung bringen wie beim SpamAssasin SPF_Fail und SPF_Softfail definiert werden.

[NorbertFe 1.805]

vor 2 Minuten schrieb Lukikum:

SpamAssasin SPF_Fail und SPF_Softfail definiert werden.

Mails anzunehmen um dann die Verarbeitung hinten zu erledigen ist bei Spam äußerst kontraproduktiv in meinen Augen. Dann nimmst du dem Spammer den Mist ja trotzdem ab um ihn dann zu löschen/quarantänieren/zuzustellen. Keine der drei Möglichkeiten ist wirklich sinnvoll IMHO. Aber da ich eure Anforderungen und Umgebung nicht kenne, mag das ja irgendeinen verborgenen Sinn haben. ;)

[Lukikum 6]

vor 14 Minuten schrieb NorbertFe:

Mails anzunehmen um dann die Verarbeitung hinten zu erledigen ist bei Spam äußerst kontraproduktiv in meinen Augen. Dann nimmst du dem Spammer den Mist ja trotzdem ab um ihn dann zu löschen/quarantänieren/zuzustellen. Keine der drei Möglichkeiten ist wirklich sinnvoll IMHO. Aber da ich eure Anforderungen und Umgebung nicht kenne, mag das ja irgendeinen verborgenen Sinn haben. ;)

Also momentan wird die Spamerkennung bei unserem Smarthost Anbieter über Spamassasin gemacht. Dort werden natürlich schon viele Mails automatisch geblockt oder als Spam markiert. Die Mails die durchkommen oder falsch markiert werden leiten wir dann an einen Spamtrainer weiter um den Algorithmus zu traineren.

 

Wir hatten letztens aber den Fall dass jemand die Adresse von unserer GF gefälscht hat und nicht als Spam markiert wurde. Meine Idee war es jetzt dass der Smarthost Mails die einen SPF_Fail oder SPF_Softfail vorweisen,  mit einem Header versehen, damit ich beim Exchange eine Regel machen kann um die Mails als "Extern" zu markieren. Wenn ihr jetzt sagt, dass best practice bei einem SPF_Fail einfach blocken ist, wäre das natürlich dann überflüssig.

 

bearbeitet 20. Juli 2022 von Lukikum

[NorbertFe 1.805]

vor 2 Minuten schrieb Lukikum:

die Adresse von unserer GF gefälscht hat und nicht als Spam markiert wurde.

Habt ihr denn SPF, DKIM und DMARC für eure Umgebung? ;) Oder gehört ihr auch zu denen 

 

vor 17 Stunden schrieb Lukikum:

da nicht jeder Geschäftspartner SPF Records veröffentlicht hat.

? ;)

[testperson 1.534]

vor 20 Minuten schrieb Lukikum:

Wir hatten letztens aber den Fall dass jemand die Adresse von unserer GF gefälscht hat und nicht als Spam markiert wurde.

Sofern ihr keine (externe) Anwendung habt die das benötigt, verbietet doch am Smarthost "einfach" die eigene Domain als Absender.

[Lukikum 6]

vor 10 Minuten schrieb testperson:

Sofern ihr keine (externe) Anwendung habt die das benötigt, verbietet doch am Smarthost "einfach" die eigene Domain als Absender.

Leider haben wir Anwendungen die das benötigen. Ich kann leider auch nicht selber einsehen wie das Regelwerk beim Smarthost funktioniert. Man kann bei deren Regeln leider auch keine IP basierte Ausnahme machen.

 

vor 32 Minuten schrieb NorbertFe:

Habt ihr denn SPF, DKIM und DMARC für eure Umgebung? ;) Oder gehört ihr auch zu denen

Wir haben einen SPF Record, aber von DKIM und DMARC weiß ich nichts. Ich bin leider auch erst seit einem Monat dabei die ganzen Thematiken der Mail Administration aufzuarbeiten. Ich hab Mxtoolbox benutzt um das zu überprüfen.

 

vor 32 Minuten schrieb NorbertFe:

? ;)

Worauf willst du hinaus ?

bearbeitet 20. Juli 2022 von Lukikum

[NorbertFe 1.805]

Ich wollte darauf hinaus:

Zitat

die ohne SPF Records ja auch keine Probleme mit SPF Records. ;) (Dafür dann halt andere Probleme). 

 

bearbeitet 20. Juli 2022 von NorbertFe

[Lukikum 6]

vor 1 Minute schrieb NorbertFe:

Ich wollte darauf hinaus:

Achso ja, ich bin mir nur nicht sicher wie die Kriterien bei Spamassasin für SPF_Fails/Softfails sind. Evtl reicht es ja auch schon dass sie kein SPF Record gepublished haben um einen SPF_Fail/Softfail im Spamassasin auszulösen.  Die dann zu blocken wäre schlecht.