Mail von Amazon oder nicht?

[accC]

Ansonsten bin ich aber in dem Thema nicht firm genug, um solche Mails anhand dieser Daten immer richtig einzusortieren

Der Return-Path enthält alle an der Übertragung beteiligten Mailserver in umgekehrter Reihenfolge.

Return Path: d --> e
Return Path: c --> d
Return Path: b --> c
Return Path: a --> b

heißt so viel wie: a hat eine Email an b geschickt, b hat sie nach c weitergeleitet und c nach d und d nach e.

Irgendwo hatte ich das mal mit konkreten Daten gezeigt, wie eine Mail von facebook zu gmx geleitet wurde, wenn ich mich recht entsinne. Hier habe ich mal an konkreten Daten gezeigt, wie sowas aussehen kann.
Wenn du dir IP-Adressen und Domains genauer anschaust, dann kannst du so die Route der Emails und die Zwischenstationen schön verfolgen.
Eigentlich ist das nur ein wenig Übungssache.

 

[malvar]

"Kommen Sie dieser Bestätigung nicht nach, sind wir gezwungen Ihr Nutzerkonto zu deaktivieren."

Bei so einem Satz sollten sofort alle Alarmglocken losgehen! Keine Firma würde das so formulieren.
In einer echten Aufforderung irgendetwas zu tun, wird eigentlich immer eine genaue Frist genannt und im Normalfall auch heutzutage kein Link mehr mitgeschickt, sondern nur mitgeteilt, dass man sich über die Homepage einloggen soll.

Im Prinzip kann man eigentlich davon ausgehen, dass alles was einen Link beinhaltet mit der Aufforderung diesen anzuklicken und nicht bewusst angefordert wurde, sehr verdächtig ist und selbst wenn es doch echt sein sollte, schadet es nie, die Adresse der eigentlichen Seite manuell einzugeben. Bei wichtigen Dingen wird man spätestens nach dem Login einen Link finden, der einen dorthin führt, wo auch die Email einen hingeleitet hätte.

 

[BurnerR]

@accC dazu habe ich eine Frage.
Die Einträge kommen vermutlich immer vom Empfänger?
Ich könnte doch auch selber Received Einträge reinschreiben beim Abschicken der Mail und den ursprünglichen Absender so zumindest teilweise verschleiern, oder? Also so das zumindest ganz unten eine Adresse steht, die mir genehm ist.
Geht das prinzipiell nicht oder macht man sich einfach nicht den Aufwand?

 

[accC]

Ja, theoretisch kann ein Empfänger bewusst die voraus gegangenen Einträge manipulieren. Einige Provider werben soweit ich weiß auch explizit damit, dass deine Absender-IP (also a) nicht erscheint. Stattdessen wird dann (irgend)eine IP eingesetzt. Also zum Beispiel so, als käme die Nachricht direkt von dem Mailprovider.
Zur Frage "ist es manipulierbar" würde ich also ja sagen. Zur Frage, wie einfach das ist, müsstest du einen Technikexperten fragen.. So genau kenne ich mich damit allerdings nicht aus. Schätze aber, dass das nur 2-3 Einstellungen sind, die man dem MTA übergeben muss. @Kugelfisch dürfte da allerdings der bessere Ansprechpartner sein.

 

[Kugelfisch]

Die Received-Zeilen bei E-Mails funktionieren ähnlich wie die X-Forwarded-For-Ketten von HTTP-Proxies, d.h. jeder MTA auf dem Weg vom Absender zum Empfänger fügt eine Received-Zeile ein, wenn er die E-Mail annimmt. Allerdings besteht keine Möglichkeit, die Authentizität der Received-Zeilen, welche bereits in der E-Mail stehen, zu überprüfen. Daher ist die Kette nur bis zum letzten vertrauenswürdigen MTA vertrauenswürdig. In deinem Fall ist dies die Zeile `Received from marx.ighz.pl ... by mx-ha.web.de`. Die weiteren Zeilen können, müssen aber nicht authentisch sein.

Meine Vermutung ist, dass die in diesem Fall die weiteren Zeilen durchaus authentisch sind und marx.ighz.pl temporär ein offenes Relay war. Allerdings hätte sich die Konfiguration dann in der Zwischenzeit geändert, da inzwischen von marx.ighz.pl:25 keine E-Mails mehr weitergeleitet werden und auch keine nicht auflösbaren Hostnamen wie `windrdpbkazingfastio` im HELO/EHLO mehr akzeptiert werden:

$ telnet marx.ighz.pl 25
Trying 85.219.163.206...
Connected to marx.ighz.pl.
< 220 marx.ighz.pl ESMTP Postfix
> HELO foo
< 250 marx.ighz.pl
> MAIL FROM: <foo@example.com>
< 250 2.1.0 Ok
> RCPT TO: <kugelfisch@ngb.to>
< 450 4.7.1 <foo>: Helo command rejected: Host not found
> quit

$ telnet marx.ighz.pl 25
Trying 85.219.163.206...
Connected to marx.ighz.pl.
< 220 marx.ighz.pl ESMTP Postfix
> helo example.com
< 250 marx.ighz.pl
> MAIL FROM: <foo@example.com>
< 250 2.1.0 Ok
> RCPT TO: <kugelfisch@ngb.to>
< 554 5.7.1 <kugelfisch@ngb.to>: Relay access denied
> quit
< 221 2.0.0 Bye

 

[accC]

Wow, es funktioniert ja echt dich zu referenzieren, wenn man technische Fakten haben möchte.
Sollte ich mir unbedingt merken.

Woher weißt du das mit dem Relay? Hast du getestet oder irgendwo nachgelesen?

 

[Kugelfisch]

Woher weißt du das mit dem Relay? Hast du getestet oder irgendwo nachgelesen?

Dass der MTA aktuell kein offenes Relay mehr ist und keine E-Mails von Clients mehr annimmt, welche einen nicht auflösbaren Hostnamen im HELO/EHLO übergeben, habe ich - wie den angehängten Logs zu entnehmen ist - getestet. Dass der Host ein offenes Relay war, ist bloss eine Vermutung. Denkbare Alternativen wären, dass die Received-Zeilen von marx.ighz.pl gefälscht wurden, oder dass ein Benutzerkonto übernommen und eine korrekte SMTP-Authentifizierung durchgeführt wurde, um den Relay-Zugriff freizugeben.