Phishing mail

[Herbert Kleebauer]

Kann man die Mailheader tatsächlich so fälschen oder ist
diese mail wirklich über den Server der Targobank gegangen?

Bis auf die russische Empfängeradresse der Daten:

<form onsubmit="return chkFormular() name="Formular" method="POST"
action="http://targobank.de.sicherer-zahlen.ru/targo/de/konto/targobank/targo.php" >

werden alle anderen Daten von Targobank Seite geladen:

<link type="text/css" rel="stylesheet" href="https://www.targobank.de/de/css/v3commun.css" />
<script type="text/javascript" src="https://www.targobank.de/de/javascript/appli/menu/menutargo.js"></script>
<img alt="TARGOBANK Online Kredit Bank" src="https://www.targobank.de/de/images/css/env/logo.gif " />


===============================================================================================

X-Envelope-From: <ser...@targobank.de>
X-Envelope-To: <??@unibwm.de>
X-Delivery-Time: 1458983612
X-UID: 3073
Return-Path: <ser...@targobank.de>
Authentication-Results: strato.com 1;
spf=softfail
smtp.mailfrom="ser...@targobank.de";
dkim=none;
domainkeys=none;
dkim-adsp=none
header.from="ser...@targobank.de"
X-Strato-MessageType: email
X-RZG-CLASS-ID: mi
Received-SPF: softfail
client-ip=212.227.8.37;
helo="mail.targobank.de";
envelope-from="ser...@targobank.de";
receiver=smtp.rzone.de;
identity=mailfrom;
Received: from mail.targobank.de (targobank.de [212.227.8.37])
by smtp.rzone.de (RZmta 37.22 OK)
with ESMTP id f03a83s2Q9DW1x0
for <??@unibwm.de>;
Sat, 26 Mar 2016 10:13:32 +0100 (CET)
Received: from [212.227.72.105] (unknown [212.227.72.105])
by mail.targobank.de (Postfix) with ESMTPSA id 02E87F0EE7
for <??@unibwm.de>; Sat, 26 Mar 2016 09:13:31 +0000 (UTC)
Message-Id: <uvxb3cgCrO3zIno7uwEzXt...@targobank.de>
Mime-Version: 1.0
From: TARGOBANK <ser...@targobank.de>
To: ??@unibwm.de
Subject: =?iso-8859-1?Q?=C4nderung_Ihres_Telefon-Banking_Pin?=
Date: Sat, 26 Mar 2016 09:13:31 GMT

[Ulli Horlacher]

Herbert Kleebauer <kl...@unibwm.de> wrote:
> Kann man die Mailheader tatsächlich so fälschen oder ist
> diese mail wirklich über den Server der Targobank gegangen?
>
>

Du solltest header nicht umformatieren, das erschwert die Lesbarkeit
erheblich.

Unter der Annahme, dass smtp.rzone.de ordentlich logged, kam die Mail von
targobank.de

Allerdings ist das eine komische Bank, die ihre Server bei 1&1 hosted.

inetnum: 212.227.0.0 - 212.227.13.255
netname: SCHLUND-CUSTOMERS
descr: 1&1 Internet AG

Alleine das riecht schon SEHR komisch.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horl...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-68565868
Allmandring 30a Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Juergen P. Meier]

Herbert Kleebauer <kl...@unibwm.de>:

> Kann man die Mailheader tatsächlich so fälschen oder ist
> diese mail wirklich über den Server der Targobank gegangen?
>

> Received: from mail.targobank.de (targobank.de [212.227.8.37])
> by smtp.rzone.de (RZmta 37.22 OK)
> with ESMTP id f03a83s2Q9DW1x0
> for <??@unibwm.de>;

rzone ist dein MTA?

Dann verifiziert er das HELO nicht richtig. Das ist eine
HELO-Faelschung wie sie im Buche steht.

Alles nach dieser Zeile ist frei erfunden weil vom einliefernden
System nach belieben gesetzt.

> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
> Received: from [212.227.72.105] (unknown [212.227.72.105])
> by mail.targobank.de (Postfix) with ESMTPSA id 02E87F0EE7
> for <??@unibwm.de>; Sat, 26 Mar 2016 09:13:31 +0000 (UTC)
> Message-Id: <uvxb3cgCrO3zIno7uwEzXt...@targobank.de>
> Mime-Version: 1.0
> From: TARGOBANK <ser...@targobank.de>
> To: ??@unibwm.de
> Subject: =?iso-8859-1?Q?=C4nderung_Ihres_Telefon-Banking_Pin?=
> Date: Sat, 26 Mar 2016 09:13:31 GMT

Beschwer dich bitte beim Betreiber von rzone.de darueber, dass ihr
Mailserver geflissentlich jeden Unsinn ohne Verifikation glaubt, den
ihm fremde Mailserver erzaehlen. (HELO mit Reverse-PTR Faelschung)

Moderne Mailsysteme verifizieren, dass folgendes zueinander passt:

1. Die IP Adresse des einliefernden Mailsystems muss rueckwaerts
aufloesen auf einen Hostnamen.
2. Dieser Hostname muss vorwaerts auf die IP-Adresse aufloesen.
3. Der HELO Parameter muss ebenfalls auf diese IP-Adresse aufloesen
Dabei muessen HELO und PTR der IP-Adresse nicht uebereinstimmen, aber
beide muessen auf diese IP-Adresse aufloesen.

Nur so kann die Faelschung dieses Betrugs erkannt werden.

Apropos: Schlund aka Eins-und-Eins macht sich als Mitstoerer haftbar,
wenn sie diesen Server noch weiter am Netz lassen nachdem du sie als
potentielles Opfer des Bankbetruegers sie darauf hingewiesen hast.

Ansonsten freut sich auch die Polizei ueber jeden Hinweis zu solchen
Betruegern, insb. wenn sie zumindest zum Teil innerhalb Deutschlands
operieren.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

begin 1 followup to Ulli Horlacher <fram...@rus.uni-stuttgart.de>:

Unfug.

Die Mail kam von einem System bei Schlund (1&1), das von
sich behauptet, "targobank.de" zu heissen.

Mit der Domain targobank.de hat das ansonsten nichts zu tun.

> Allerdings ist das eine komische Bank, die ihre Server bei 1&1 hosted.
>
> inetnum: 212.227.0.0 - 212.227.13.255
> netname: SCHLUND-CUSTOMERS
> descr: 1&1 Internet AG
>
> Alleine das riecht schon SEHR komisch.

Das richt nicht nur komisch, das ist eine voellig handelsuebliche
Faelschung.

Jeder Depp kann das bei Hostern wie Schlund mit einem Klick hinfummeln.

[Herbert Kleebauer]

On 26.03.2016 11:41, Ulli Horlacher wrote:

> Du solltest header nicht umformatieren, das erschwert die Lesbarkeit
> erheblich.

War keine Absicht. Thunderbird ignoriert bei einem Paste anscheinend
alle Tabs am Zeilenanfang.

[Herbert Kleebauer]

On 26.03.2016 11:50, Juergen P. Meier wrote:


>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>> by smtp.rzone.de (RZmta 37.22 OK)
>> with ESMTP id f03a83s2Q9DW1x0
>> for <??@unibwm.de>;

>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)

> Alles nach dieser Zeile ist frei erfunden weil vom einliefernden
> System nach belieben gesetzt.

Entscheidend sind aber eben obige Zeilen. Ein nslookup liefert

nslookup 212.227.8.37

Name: targobank.de
Address: 212.227.8.37


d.h. die mail scheint tatsächlich von targobank.de an Strato
geliefert wurden zu sein. Was immer davor war kann natürlich
gefälscht sein.


> rzone ist dein MTA?

unibwm.de ist bei Strato gehostet.

[Herbert Kleebauer]

On 26.03.2016 12:00, Juergen P. Meier wrote:

> Die Mail kam von einem System bei Schlund (1&1), das von
> sich behauptet, "targobank.de" zu heissen.

Soll das heißen, man kann auch den Angaben des nameservers
nicht mehr vertrauen? Kann jeder für seine IP Adresse einen
fremden Domainnamein eintragen lassen?


tracert 212.227.8.37

Routenverfolgung zu targobank.de [212.227.8.37] über maximal 30 Abschnitte:

1 1 ms 1 ms <1 ms speedport.ip [192.168.2.1]
2 22 ms 22 ms 21 ms 217.0.117.46
3 23 ms 23 ms 22 ms 87.190.170.182
4 33 ms 32 ms 32 ms ka-ea4-i.KA.DE.NET.DTAG.DE [62.154.74.62]
5 32 ms 32 ms 32 ms ka-ea4-i.KA.DE.NET.DTAG.DE [62.154.74.62]
6 35 ms 36 ms 36 ms dtag.bb-a.tp.kae.de.oneandone.net [80.156.160.54]
7 33 ms 34 ms 34 ms ae-3-0.bb-a.bap.rhr.de.oneandone.net [212.227.120.45]
8 * 78 ms 48 ms ae-10.gw-distp-a.bap.rhr.de.oneandone.net [212.227.121.165]
9 35 ms 34 ms 34 ms 212.227.218.15
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * ^C


tracert 145.226.46.149

Routenverfolgung zu targobank.de [145.226.46.149] über maximal 30 Abschnitte:

1 1 ms 1 ms 1 ms speedport.ip [192.168.2.1]
2 22 ms 22 ms 21 ms 217.0.117.46
3 22 ms 23 ms 23 ms 87.190.170.182
4 32 ms 35 ms 35 ms f-eb2-i.F.DE.NET.DTAG.DE [62.154.17.98]
5 31 ms 60 ms 60 ms 80.157.129.70
6 45 ms 45 ms 44 ms et-5-0-0.GW7.SDE2.ALTER.NET [140.222.232.239]
7 55 ms 56 ms 56 ms 212.208.19.14
8 51 ms 51 ms 51 ms 10.242.1.1
9 57 ms 54 ms 56 ms 10.242.129.19
10 55 ms 55 ms 55 ms 10.242.128.62
11 53 ms 52 ms 53 ms targobank.de [145.226.46.149]

Ablaufverfolgung beendet.

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:
>begin 1 followup to Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
>> Herbert Kleebauer <kl...@unibwm.de> wrote:
>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>> by smtp.rzone.de (RZmta 37.22 OK)
>>> with ESMTP id f03a83s2Q9DW1x0
>>> for <??@unibwm.de>;
>>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>>
>> Du solltest header nicht umformatieren, das erschwert die Lesbarkeit
>> erheblich.
>>
>> Unter der Annahme, dass smtp.rzone.de ordentlich logged, kam die Mail von
>> targobank.de
>
>Unfug.
>
>Die Mail kam von einem System bei Schlund (1&1), das von
>sich behauptet, "targobank.de" zu heissen.
>
>Mit der Domain targobank.de hat das ansonsten nichts zu tun.

Erwarte ich zuu viel, wenn ich hoffen würde, dass smtp.rzone.de nur
hostnamen in seine Received-Header schreibt, bei denen der DNS
vorwärte _und_ rückwärts passt?

Außerdem finde ich das sehr interessant, dass der Reverse eingetragen
wurde. Normalerweise prüft 1&1 beim Eintrag von Reverse DNS Records ob
der Forward passt.

>Jeder Depp kann das bei Hostern wie Schlund mit einem Klick hinfummeln.

Nicht unbedingt.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Herbert Kleebauer <kl...@unibwm.de> wrote:
>Entscheidend sind aber eben obige Zeilen. Ein nslookup liefert
>
>nslookup 212.227.8.37
>
>Name: targobank.de
>Address: 212.227.8.37

Richtig. Aber:

targobank.de löst vorwärts nicht auf 212.227.8.37 auf. Das würden die
Systeme von 1&1 so nicht akzeptieren. Es sei denn, der Forward-Eintrag
hat gestimmt als der Reverse-Eintrag gemacht wurde.

>d.h. die mail scheint tatsächlich von targobank.de an Strato
>geliefert wurden zu sein.

Nein, das kannst Du erst dann mit Sicherheit sagen wenn der Forward
auch stimmt.

[Andreas Kohlbach]

Ulli Horlacher wrote on 26. March 2016:
>
> Herbert Kleebauer <kl...@unibwm.de> wrote:
>> Kann man die Mailheader tatsächlich so fälschen oder ist
>> diese mail wirklich über den Server der Targobank gegangen?

[...]

> Unter der Annahme, dass smtp.rzone.de ordentlich logged, kam die Mail von
> targobank.de
>
> Allerdings ist das eine komische Bank, die ihre Server bei 1&1 hosted.
>
> inetnum: 212.227.0.0 - 212.227.13.255
> netname: SCHLUND-CUSTOMERS
> descr: 1&1 Internet AG
>
> Alleine das riecht schon SEHR komisch.

>> Warum schauen sich alle hier nur die Header an? Der teilweise von Ulli
>> gepostete Body sieht IMO auch interessant aus:

>>
>> Kann man die Mailheader tatsächlich so fälschen oder ist
>> diese mail wirklich über den Server der Targobank gegangen?
>

>> Bis auf die russische Empfängeradresse der Daten:
>
>> <form onsubmit="return chkFormular() name="Formular" method="POST"
>> action="http://targobank.de.sicherer-zahlen.ru/targo/de/konto/targobank/targo.php" >

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Natürlich kann man einer Deutschen Bank mit langer Adresse und Russischer
TLD voll und ganz vertrauen. ;-)

Die Seite scheint bei Sedoparking zu sein, ist aber trotzdem aktiv, so
dass das Formular in der Mail - was eher ist selten ist, funktionieren
wird.

sicherer-zahlen.ru löst nach 83.217.25.163 auf, was firstbyte.ru ist. Ob
die auf Beschwerden reagieren, wage ich zu bezweifeln, weil ich dazu
neige, in Putin-Land alles über einen Kamm zu scheren und für korrupt
und verkommen zu empfinden. Aber vielleicht gibt es Fälle, wo ich
Unrecht habe.

Besser scheint mir de.admin.net-abuse.mail zu sein, dass ich mal dorthin
weiter leite.
--
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[Arno Welzel]

Herbert Kleebauer schrieb am 2016-03-26 um 11:03:

> Kann man die Mailheader tatsächlich so fälschen oder ist
> diese mail wirklich über den Server der Targobank gegangen?

[...]

> Received: from mail.targobank.de (targobank.de [212.227.8.37])

Nein.



--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[Peter J. Holzer]

On 2016-03-26 22:57, Arno Welzel <use...@arnowelzel.de> wrote:
> Herbert Kleebauer schrieb am 2016-03-26 um 11:03:
>> Kann man die Mailheader tatsächlich so fälschen oder ist
>> diese mail wirklich über den Server der Targobank gegangen?
> [...]
>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>
> Nein.

Auf eine Entweder-Oder-Frage korrekt mit Nein zu antworten, gelingt
nicht jeden Tag. Tertium datur!

hp


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[Marc Haber]

"Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>On 2016-03-26 22:57, Arno Welzel <use...@arnowelzel.de> wrote:
>> Herbert Kleebauer schrieb am 2016-03-26 um 11:03:
>>> Kann man die Mailheader tatsächlich so fälschen oder ist
>>> diese mail wirklich über den Server der Targobank gegangen?
>> [...]
>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>
>> Nein.
>
>Auf eine Entweder-Oder-Frage korrekt mit Nein zu antworten, gelingt
>nicht jeden Tag. Tertium datur!

Auf fundiertere Antworten wird in diesem Thread ja geschwiegen[1],
insoweit finde ich Arnos Reaktion durchaus angemessen.

Grüße
Marc

[1] bzw die beantwortete Frage Stunden später nochmal gestellt

[Herbert Kleebauer]

On 27.03.2016 08:30, Marc Haber wrote:

> Auf fundiertere Antworten wird in diesem Thread ja geschwiegen[1],

> [1] bzw die beantwortete Frage Stunden später nochmal gestellt

Das zielt wohl auf mich. Ich sehe weder die Antwort auf die
man hätte antworten können/sollen noch die selbe Frage ein
paar Stunden später. Könntest du bitte deine Anschuldigungen
etwas konkretisieren.

[dl8...@dl8fbh.ampr.org]

Herbert Kleebauer <kl...@unibwm.de> wrote:

> On 27.03.2016 08:30, Marc Haber wrote:
>
>> Auf fundiertere Antworten wird in diesem Thread ja geschwiegen[1],
>

>> [1] bzw die beantwortete Frage Stunden sp?ter nochmal gestellt

>
> Das zielt wohl auf mich. Ich sehe weder die Antwort auf die

> man h?tte antworten k?nnen/sollen noch die selbe Frage ein
> paar Stunden sp?ter. K?nntest du bitte deine Anschuldigungen
> etwas konkretisieren.
>

targobank.de has address 145.226.46.149
targobank.de mail is handled by 20 smtp1-inzi.e-i.net.
targobank.de mail is handled by 10 smtp1-inyi.e-i.net.

War also alles gef?lscht.

Michael


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Peter J. Holzer]

On 2016-03-27 06:30, Marc Haber <mh+usene...@zugschl.us> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>>On 2016-03-26 22:57, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Herbert Kleebauer schrieb am 2016-03-26 um 11:03:
>>>> Kann man die Mailheader tatsächlich so fälschen oder ist
>>>> diese mail wirklich über den Server der Targobank gegangen?
>>> [...]
>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>>
>>> Nein.
>>
>>Auf eine Entweder-Oder-Frage korrekt mit Nein zu antworten, gelingt
>>nicht jeden Tag. Tertium datur!
>
> Auf fundiertere Antworten wird in diesem Thread ja geschwiegen[1],
> insoweit finde ich Arnos Reaktion durchaus angemessen.

Oh, das war keine Kritik, sondern ein Lob. Arno hat in bester
Donnerhackescher Tradition eine Ein-Wort-Antwort gegeben, die korrekt
ist, obwohl sie auf den ersten Blick überhaupt nicht zur Frage zu passen
scheint. Da denkt man zuerst "WTF?", dann denkt man ein paar Sekunden
darüber nacht und stellt fest, dass er recht hat. Die Alternativen
treffen tatsächlich beide nicht zu und es gibt eine dritte Möglichkeit.

(Besonders hilfreich ist so eine Antwort natürlich nicht, aber amüsant.)

[Herbert Kleebauer]

On 27.03.2016 11:30, dl8...@dl8fbh.ampr.org wrote:

> targobank.de has address 145.226.46.149
> targobank.de mail is handled by 20 smtp1-inzi.e-i.net.
> targobank.de mail is handled by 10 smtp1-inyi.e-i.net.
>
> War also alles gef?lscht.

Ganz so einfach ist die Fälschung aber nicht. Denn der Headereintrag:

Received: from mail.targobank.de (targobank.de [212.227.8.37])

by smtp.rzone.de (RZmta 37.22 OK)
with ESMTP id f03a83s2Q9DW1x0
for <??@unibwm.de>;
Sat, 26 Mar 2016 10:13:32 +0100 (CET)

konnte ja nicht vom Absender gefälscht werden, er wurde ja
vom Empfänger generiert. Die Fälschung fand indirekt über
einen gefälschten DNS Eintrag statt. Das ist so als ob
ich einen Anruf von der Bank bekommen und um sicher zu
gehen anschließend die Nummer mit der Rückwärtssuche im
Telefonbuch der Telekom nachsehe und die mir für
diese Telefonnummer tatsächlich die Bank als Nutzer
anzeigt.

Ich weiß nur nicht, wer jetzt die Verantwortung für den
falschen DNS Eintrag trägt.

Z.Z. liefert der DNS immer noch:

[Herbert Kleebauer]

On 27.03.2016 12:21, Peter J. Holzer wrote:

>>>>> Kann man die Mailheader tatsächlich so fälschen oder ist
>>>>> diese mail wirklich über den Server der Targobank gegangen?
>>>> [...]
>>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])

>>>> Nein.

> Oh, das war keine Kritik, sondern ein Lob. Arno hat in bester
> Donnerhackescher Tradition eine Ein-Wort-Antwort gegeben, die korrekt
> ist, obwohl sie auf den ersten Blick überhaupt nicht zur Frage zu passen
> scheint.

Ein "nein" für beides schließt sich ja (nicht nur auf den ersten Blick)
aus. Tatsächlich ist er ja gefälscht, nur nicht vom Absender sondern
vom Empfänger. Der Absender hat den DNS Eintrag gefälscht und daraufhin
hat der Empfänger diese falsche Information in den Header übernommen.

[Marc Haber]

Herbert Kleebauer <kl...@unibwm.de> wrote:
>Received: from mail.targobank.de (targobank.de [212.227.8.37])
> by smtp.rzone.de (RZmta 37.22 OK)
> with ESMTP id f03a83s2Q9DW1x0
> for <??@unibwm.de>;
> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>
>konnte ja nicht vom Absender gefälscht werden, er wurde ja
>vom Empfänger generiert.

Genau, der hätte so von smtp.rzone.de nicht generiert werden dürfen
(weil der Forward nicht stimmt). Außerdem ist fraglich, wie der Mieter
des vermuteten Servers auf 212.227.8.37 targobank.de als reverse hat
eintragen können (weil die Systeme von 1&1 den Eintrag eines Reverse
erst dann zulassen, wenn sie geprüft haben, dass der passende Forward
schon da ist).

>Ich weiß nur nicht, wer jetzt die Verantwortung für den
>falschen DNS Eintrag trägt.

Der Kunde von 1&1 an erster Stelle, 1&1 an zweiter Stelle.

Grüße
Marc

[Peter J. Holzer]

On 2016-03-27 11:03, Herbert Kleebauer <kl...@unibwm.de> wrote:
> On 27.03.2016 12:21, Peter J. Holzer wrote:
>>>>>> Kann man die Mailheader tatsächlich so fälschen oder ist
>>>>>> diese mail wirklich über den Server der Targobank gegangen?
>>>>> [...]
>>>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>
>>>>> Nein.
>
>
>> Oh, das war keine Kritik, sondern ein Lob. Arno hat in bester
>> Donnerhackescher Tradition eine Ein-Wort-Antwort gegeben, die korrekt
>> ist, obwohl sie auf den ersten Blick überhaupt nicht zur Frage zu passen
>> scheint.
>
>
> Ein "nein" für beides schließt sich ja (nicht nur auf den ersten Blick)
> aus. Tatsächlich ist er ja gefälscht,

Nein, ist er nicht. Jedenfalls für keine Definition von "gefälscht", die
mir einfällt.

> nur nicht vom Absender sondern vom Empfänger.

Warum sollte der Empfänger das tun? Und er hat es ja auch nicht getan.
Der Header enthält (soweit wir wissen) völlig korrekt Informationen, die
der Empfänger zum Zeitpunkt des Empfangs hatte:

Der Hostname aus EHLO, der Wert des PTR-Records zur Client-IP-Adresse
und die Client-IP-Adresse.

Dass das nicht die Information ist, die Du dort zu sehen erwartet hast,
ist keine Fälschung (also bewusste Täuschung) durch den Empfänger,
sondern Mangel an Erfahrung Deinerseits. (Schlimmstenfalls ist es
Nachlässigkeit des Empfängers: Denn natürlich hätte er (bzw. der Autor
des MTAs) dort statt dem nicht sonderlich aussagekräftigen PTR-Record
was anderes hinschreiben können).

[Peter J. Holzer]

On 2016-03-27 13:15, Marc Haber <mh+usene...@zugschl.us> wrote:
> Herbert Kleebauer <kl...@unibwm.de> wrote:
>>Received: from mail.targobank.de (targobank.de [212.227.8.37])
>> by smtp.rzone.de (RZmta 37.22 OK)
>> with ESMTP id f03a83s2Q9DW1x0
>> for <??@unibwm.de>;
>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>>
>>konnte ja nicht vom Absender gefälscht werden, er wurde ja
>>vom Empfänger generiert.
>
> Genau, der hätte so von smtp.rzone.de nicht generiert werden dürfen
> (weil der Forward nicht stimmt).

Wo steht das? In RFC 5321 kommt da zwar ein "Domain" in der BNF vor,
aber auch nach mehrmaligem Lesen von 4.4 finde ich keine Definition,
welche Domain da stehen soll. Historisch war es ziemlich üblich, dass da
das einfach das Ergebnis von gethostbyaddr(3) reingeworfen wurde. Nicht
ideal, aber dass der MTA das nicht dürfte, halte ich für überzogen.

[Herbert Kleebauer]

On 27.03.2016 15:24, Peter J. Holzer wrote:

>> Ein "nein" für beides schließt sich ja (nicht nur auf den ersten Blick)
>> aus. Tatsächlich ist er ja gefälscht,
>
> Nein, ist er nicht. Jedenfalls für keine Definition von "gefälscht", die
> mir einfällt.
>
>> nur nicht vom Absender sondern vom Empfänger.
>
> Warum sollte der Empfänger das tun? Und er hat es ja auch nicht getan.

Der Header enthält eindeutig falsche Angaben:

Received: from mail.targobank.de (targobank.de [212.227.8.37])

Und diese falsche Information wurde absichtlich generiert um
die Zielperson der Mail zu täuschen. Damit ist es für mich eine
Fälschung. Das der empfangende Server dies nicht bewusst gemacht
hat, sondern vom Sender missbraucht wurde, ändert daran nichts.

> Dass das nicht die Information ist, die Du dort zu sehen erwartet hast,
> ist keine Fälschung (also bewusste Täuschung) durch den Empfänger,

Es ist eine bewusste Täuschung. Sie wurde vom Empfänger generiert
(der allerdings nichts davon wusste) und vom Sender trickreich
initiiert.

Wie auch immer, jedenfalls war die Phishing-Mail diesbezüglich
gut gemacht. Hätte nie gedacht, dass man dem DNS nicht vertrauen
darf. Ich sehe mir ab und zu mal die Header von Spam an, so was
habe ich bisher aber noch nicht gesehen. Auch der html-Body war gut
gemacht, bis auf den POST-Server für das Formular nur Verweise
auf die Targobank. Enttäuschen ist allerdings das Subject:
"Änderung Ihres Telefon-Banking Pin" und dass man das html
base64 codiert hat.

Wenn ich Kunde der Bank wäre, die ein vernünftiges Subject
gewählt hätten und den html Teil nicht base64 codiert hätten,
hätte ich die Mail möglicherweise gelesen.

[Peter J. Holzer]

On 2016-03-27 15:15, Herbert Kleebauer <kl...@unibwm.de> wrote:
> On 27.03.2016 15:24, Peter J. Holzer wrote:
>
>>> Ein "nein" für beides schließt sich ja (nicht nur auf den ersten Blick)
>>> aus. Tatsächlich ist er ja gefälscht,
>>
>> Nein, ist er nicht. Jedenfalls für keine Definition von "gefälscht", die
>> mir einfällt.
>>
>>> nur nicht vom Absender sondern vom Empfänger.
>>
>> Warum sollte der Empfänger das tun? Und er hat es ja auch nicht getan.
>
> Der Header enthält eindeutig falsche Angaben:
> Received: from mail.targobank.de (targobank.de [212.227.8.37])

Was ist daran falsch? Der PTR-Record existiert. Du kannst Dich jederzeit
davon überzeugen:

% dig -x 212.227.8.37

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 212.227.8.37
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6694
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;37.8.227.212.in-addr.arpa. IN PTR

;; ANSWER SECTION:
37.8.227.212.in-addr.arpa. 300 IN PTR targobank.de.

;; AUTHORITY SECTION:
227.212.in-addr.arpa. 77664 IN NS rns.ui-dns.com.
227.212.in-addr.arpa. 77664 IN NS rns.ui-dns.org.
227.212.in-addr.arpa. 77664 IN NS rns.ui-dns.de.
227.212.in-addr.arpa. 77664 IN NS rns.ui-dns.biz.

;; ADDITIONAL SECTION:
rns.ui-dns.de. 77664 IN A 217.160.80.213
rns.ui-dns.de. 77664 IN AAAA 2001:8d8:fe:53:0:d9a0:50d5:100
rns.UI-DNS.biz. 77664 IN A 217.160.81.213
rns.UI-DNS.biz. 77664 IN AAAA 2001:8d8:fe:53:0:d9a0:51d5:100
rns.ui-dns.com. 77664 IN A 217.160.82.213
rns.ui-dns.com. 77664 IN AAAA 2001:8d8:fe:53:0:d9a0:52d5:100
rns.ui-dns.org. 77664 IN A 217.160.83.213
rns.ui-dns.org. 77664 IN AAAA 2001:8d8:fe:53:0:d9a0:53d5:100

;; Query time: 70 msec
;; SERVER: 212.17.106.132#53(212.17.106.132)
;; WHEN: Sun Mar 27 17:54:25 CEST 2016
;; MSG SIZE rcvd: 376

> Und diese falsche Information wurde absichtlich generiert um die
> Zielperson der Mail zu täuschen.

Du interpretierst etwas in die Received-Zeile hinein. Dass Deine
Interpretation nicht mit der Realität übereinstimmt, ist zunächst einmal
Dein Problem. Vielleicht solltest Du daran arbeiten, Deine Erwartungen
an die Realität anzupassen.

Aber ja, natürlich hat der Phisher damit gerechnet, dass Leute das so
(oder so ähnlich) interpretieren, wie Du das tust, und hat deshalb den
PTR-Record angelegt.

>> Dass das nicht die Information ist, die Du dort zu sehen erwartet hast,
>> ist keine Fälschung (also bewusste Täuschung) durch den Empfänger,
>
> Es ist eine bewusste Täuschung. Sie wurde vom Empfänger generiert
> (der allerdings nichts davon wusste) und vom Sender trickreich
> initiiert.
>
> Wie auch immer, jedenfalls war die Phishing-Mail diesbezüglich
> gut gemacht. Hätte nie gedacht, dass man dem DNS nicht vertrauen
> darf.

Du kannst ins DNS reinschreiben, was Du willst. Ein PTR ist rein
technisch nichts anderes als "a pointer to another part of the domain
name space" (RFC 1034). Es hat ist eine Konvention, unter in-addr.arpa.
PTR-Records auf den "kanonischen" Hostnamen abzulegen, aber nichts
erzwingt das. Mehrere Leute haben in diesem Thread angemerkt, dass 1&1
normalerweise prüft, ob der Name auf die entsprechende IP-Adresse
auflöst, bevor sie den Eintrag machen, aber darauf kann man sich (wie
man sieht) nicht verlassen.

[Herbert Kleebauer]

On 27.03.2016 18:14, Peter J. Holzer wrote:

>> Der Header enthält eindeutig falsche Angaben:
>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>
> Was ist daran falsch? Der PTR-Record existiert. Du kannst Dich jederzeit
> davon überzeugen:

Das ist jetzt aber nicht mehr ernst gemeint? Der Name "targobank.de" gehört

TARGOBANK AG & Co. KGaA
Kasernenstr 10
40213 Duesseldorf

In der Received-Zeile steht, 212.227.8.37 gehört zu targobank.de und
da fragst du was daran falsch ist?

Wenn ich sage, es ist falsch dass die Telefonnummer 08944556677 zur
Targobank gehört, antwortest du, dass ist nicht falsch weil bei
einer Rückwärtssuche bei der Telekom mit dieser Nummer erhält man
die Targobank als Besitzer der Nummer. Wenn jemand einen falschen
Eintrag in eine Datenbank macht, wird er doch nicht richtig nur
weil er jetzt so in der Datenbank steht.

[Thomas Hochstein]

Marc Haber schrieb:

> Außerdem finde ich das sehr interessant, dass der Reverse eingetragen
> wurde. Normalerweise prüft 1&1 beim Eintrag von Reverse DNS Records ob
> der Forward passt.

Das wundert mich allerdings auch; ich hatte angenommen, sie würden das
jetzt nicht mehr machen.

[Peter J. Holzer]

On 2016-03-27 17:27, Herbert Kleebauer <kl...@unibwm.de> wrote:
> On 27.03.2016 18:14, Peter J. Holzer wrote:
>>> Der Header enthält eindeutig falsche Angaben:
>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>
>> Was ist daran falsch? Der PTR-Record existiert. Du kannst Dich jederzeit
>> davon überzeugen:
>
> Das ist jetzt aber nicht mehr ernst gemeint? Der Name "targobank.de" gehört
>
> TARGOBANK AG & Co. KGaA
> Kasernenstr 10
> 40213 Duesseldorf
>
> In der Received-Zeile steht, 212.227.8.37 gehört zu targobank.de

Nein, das steht da nicht.

> und da fragst du was daran falsch ist?

Wie bereits mehrmals gesagt: Du interpretierst Information in die
Received-Zeile hinein, die da nicht drin steht. Die Received-Zeile ist
nicht dafür da, rechtliche Eigentumsverhältnisse zu dokumentieren. Sie
ist dafür da, zu dokumentieren, von welchem Host eine Mail empfangen
wurde. Was da genau drin zu stehen hat, ist im RFC reichlich schwammig
definiert, aber die relevanten Teile sind:

| o The FROM clause, which MUST be supplied in an SMTP environment,
| SHOULD contain both (1) the name of the source host as presented
| in the EHLO command and (2) an address literal containing the IP
| address of the source, determined from the TCP connection.
[...]
| From-domain = "FROM" FWS Extended-Domain
[...]
| Extended-Domain = Domain /
| ( Domain FWS "(" TCP-info ")" ) /
| ( address-literal FWS "(" TCP-info ")" )
|
| TCP-info = address-literal / ( Domain FWS address-literal )
| ; Information derived by server from TCP connection
| ; not client EHLO.

Rein syntaktisch muss ein Domainname da stehen, optional dürfen in
runden Klammern ein weiterer Domainname und eine IP-Adresse folgen.
Was was ist, ist nicht genau festgelegt, aber man kann sich (vor allem,
wenn man die historische Entwicklung kennt) einiges zusammenreimen:

Einer der beiden Domainnamen SOLL der aus dem HELO/EHLO-Kommando sein. Da
aber im Kommentar zu TCP-Info "not client EHLO" steht, kann das nur der
erste, obligate Domainname sein. Das entspricht auch der historischen
Praxis. D.h., die einzige Information, die da stehen MUSS, kann vom
Client beliebig gewählt werden. Das hat sich natürlich als unzureichend
herausgestellt, weshalb die optionale TCP-Info der interessantere Teil
ist.

Der besteht aus "Information derived by server from TCP connection". Das
Address-literal ist ziemlich eindeutig: Das SOLL "the IP address of the
source, determined from the TCP connection" sein , aber was ist die
Domain? Eine TCP-Connection hat keinen Domainnamen, und der im Standard
oft bemühte "canonical host name" ist ein eher theoretisches Konstrukt
aus einer einfacheren Zeit. Was man aber machen kann, ist den zur
IP-Adresse des Clients zugehörigen PTR-Record zu suchen, und den
mitzuloggen.

Das ist das, was die Received-Zeile aussagt:

(1) Ich habe die Mail von einem Host mit der IP-Adresse 212.227.8.37
erhalten. Zum Zeitpunkt des Empfangs existierte ein PTR-Record
37.8.227.212.in-addr.arpa. IN PTR targobank.de.
Und der Client hat sich mit "EHLO mail.targobank.de" gemeldet.

Die Received-Zeile sagt nicht:

(2) Ich habe eine Mail von der TARGOBANK AG & Co. KGaA empfangen

Sie sagt auch nicht:

(3) Ich habe eine Mail von einem Host empfangen, der unter dem Namen
targobank.de bekannt ist.

Das sind Interpretationen von Dir.

Da der PTR-Record aber in der Verfügungsgewalt des Absenders liegt
(zumindest theoretisch, praktisch geben die die ISPs oft nicht her),
gehen manche Mailserver einen Schritt weiter: Sie nehmen den PTR-Record
(oder die PTR-Records, es kann meherere geben) und suchen dann die
dazugehörenden A- bzw. AAAA-Records (davon kann es auch wieder mehrere
geben). Nur wenn mindestens einer dieser Adress-Records der
ursprünglichen IP-Adresse entspricht, gilt der Name als
"vertrauenswürdig" oder "verifiziert" und wird in den Received-Header
aufgenommen. Das hat den Vorteil, dass es Aussage (3) entspricht und der
Intuition vieler Leute entgegenkommt (und natürlich den Nachteil, dass
vorhandene Information verworfen wird).

Da der Standard aber nicht vorschreibt, auf welche Art der Domainname
ermittelt werden soll, kannst Du Dich nicht darauf verlassen, dass das
Deiner Intuition entspricht. Du musst wissen, was der entsprechende
Mail-Server macht, sonst kannst Du die Zeile nicht richtig
interpretieren. Wenn Du das nicht weißt, dann musst Du mit Vermutungen
vorsichtig sein und darfst Dich nicht von Deinen Wunschvorstellungen
leiten lassen.

(In der Praxis gab es übrigend viele (und gibt es immer noch
vereinzelte) Mailserver, die sich überhaupt nicht an das von RFC 2821
standardisierte Format halten, sondern ausgehend von RFC 821 ein eigenes
entwickelt haben. Einige dieser Formate waren IMHO deutlich besser
durchdacht, als das, was dann standardisiert wurde, aber natürlich hat der
Wildwuchs die Interpretation von Received-Zeilen zu einer wilden Raterei
gemacht.)

> Wenn ich sage, es ist falsch dass die Telefonnummer 08944556677 zur
> Targobank gehört, antwortest du, dass ist nicht falsch weil bei
> einer Rückwärtssuche bei der Telekom mit dieser Nummer erhält man
> die Targobank als Besitzer der Nummer.

Nein, ich sage (um bei Deinem Gleichnis zu bleiben), dass deine Quelle
niemals behauptet hat, dass diese Telefonnummer der Targobank gehöre,
sondern dass Du eine Aussage falsch verstanden hast. Aber nur, weil Du
eine Aussage falsch verstehst, und daher glaubst, es sei eine falsche
Tatsachenbehauptung aufgestellt worden, ist diese Aussage keine
Fälschung. Sie ist vielleicht missverständlich oder schlecht formuliert.
Aber zwischen einer missverständlichen Aussage und einer Fälschung ist
für mich ein großer Unterschied, selbst wenn beide die gleiche Folge
(der Adressat unterliegt einem Irrtum) haben.

[Marc Haber]

"Peter J. Holzer" <hjp-u...@hjp.at> wrote:

>On 2016-03-27 13:15, Marc Haber <mh+usene...@zugschl.us> wrote:
>> Herbert Kleebauer <kl...@unibwm.de> wrote:
>>>Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>> by smtp.rzone.de (RZmta 37.22 OK)
>>> with ESMTP id f03a83s2Q9DW1x0
>>> for <??@unibwm.de>;
>>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>>>
>>>konnte ja nicht vom Absender gefälscht werden, er wurde ja
>>>vom Empfänger generiert.
>>
>> Genau, der hätte so von smtp.rzone.de nicht generiert werden dürfen
>> (weil der Forward nicht stimmt).
>
>Wo steht das? In RFC 5321 kommt da zwar ein "Domain" in der BNF vor,
>aber auch nach mehrmaligem Lesen von 4.4 finde ich keine Definition,
>welche Domain da stehen soll. Historisch war es ziemlich üblich, dass da
>das einfach das Ergebnis von gethostbyaddr(3) reingeworfen wurde. Nicht
>ideal, aber dass der MTA das nicht dürfte, halte ich für überzogen.

Das hab ich nicht mit dem Hintergrund der formellen Standards gemeint.

[Herbert Kleebauer]

On 27.03.2016 20:50, Peter J. Holzer wrote:

>>>> Der Header enthält eindeutig falsche Angaben:
>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])

> Wie bereits mehrmals gesagt: Du interpretierst Information in die
> Received-Zeile hinein, die da nicht drin steht. Die Received-Zeile ist
> nicht dafür da, rechtliche Eigentumsverhältnisse zu dokumentieren. Sie
> ist dafür da, zu dokumentieren, von welchem Host eine Mail empfangen
> wurde.

Auch deine vielen Worte ändern nichts daran, dass die "Received:"
Zeile falsche Angaben enthält.

Wenn aus der IP Adresse der Name nicht aufgelöst werden kann,
wird entweder gar nichts oder "unknown" eingefügt.

Received: from mailproxy.nbg.petafuel.de ([62.146.54.138])
Received: from nbgbatchserver.petafuel.intern (unknown [192.168.20.8])

Falls der Name aufgelöst werden kann, wird er eingefügt:

Received: from mail.banggood.com (f6.8e.1732.ip4.static.sl-reverse.com [50.23.142.246])

Diese Namensauflösung kann nun richtig oder falsch sein. Und
es spielt keine Rolle warum sie falsch ist (falscher DNS Eintrag
oder schlichter Programmierfehler oder auch Absicht), wenn sie
falsch ist, enthält die Received-Zeile falsche Angaben.

[Arno Welzel]

Herbert Kleebauer schrieb am 2016-03-27 um 22:41:

> On 27.03.2016 20:50, Peter J. Holzer wrote:
>
>>>>> Der Header enthält eindeutig falsche Angaben:
>>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>
>> Wie bereits mehrmals gesagt: Du interpretierst Information in die
>> Received-Zeile hinein, die da nicht drin steht. Die Received-Zeile ist
>> nicht dafür da, rechtliche Eigentumsverhältnisse zu dokumentieren. Sie
>> ist dafür da, zu dokumentieren, von welchem Host eine Mail empfangen
>> wurde.
>
>
> Auch deine vielen Worte ändern nichts daran, dass die "Received:"
> Zeile falsche Angaben enthält.

Zum Zeitpunkt der Zustellung waren die Angaben völlig korrekt, da ein
PTR-Record für 212.227.8.37 existiert hat, der auf "targobank.de"
aufgelöst hat.

> Wenn aus der IP Adresse der Name nicht aufgelöst werden kann,
> wird entweder gar nichts oder "unknown" eingefügt.

Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.

> Diese Namensauflösung kann nun richtig oder falsch sein. Und
> es spielt keine Rolle warum sie falsch ist (falscher DNS Eintrag
> oder schlichter Programmierfehler oder auch Absicht), wenn sie
> falsch ist, enthält die Received-Zeile falsche Angaben.

Die Namensauflösung war nicht falsch. Es existierte ein entsprechender
PTR-Record. Und ja - je nach Provider ist das trivial anzulegen.

[Andreas Hartmann]

On 03/26/2016 at 01:10 PM Marc Haber wrote:
> Herbert Kleebauer <kl...@unibwm.de> wrote:
>> Entscheidend sind aber eben obige Zeilen. Ein nslookup liefert
>>
>> nslookup 212.227.8.37
>>
>> Name: targobank.de
>> Address: 212.227.8.37
>
> Richtig. Aber:

?

nslookup 212.227.8.37
Server: x
Address: x#53

** server can't find 37.8.227.212.in-addr.arpa.: NXDOMAIN

Bei sämtlichen von mir geprüften DNS-Servern. Auch bei heise.



Gruß,
Andreas

[Arno Welzel]

Ja - JETZT, da die fraglichen Einträge offenbar gelöscht wuden. Aber vor
etwa 2 Tagen war das anders.

[Marc Haber]

Herbert Kleebauer <kl...@unibwm.de> wrote:
>Diese Namensauflösung kann nun richtig oder falsch sein.

Sie kann auch - wie hier - ein wenig falsch sein. Du solltest Dich
wirklich mal mit DNS beschäftigen, hier insbesondere den Unterschied
zwischen Forward und Reverse.

Grüße
Marc

[Marc Haber]

Arno Welzel <use...@arnowelzel.de> wrote:
>Die Namensauflösung war nicht falsch. Es existierte ein entsprechender
>PTR-Record. Und ja - je nach Provider ist das trivial anzulegen.

Und deswegen gehört es zum guten Ton für Software, einen aus dem
reverse DNS ausgelesenen Hostnamen nur als "richtig" anzunehmen, wenn
die Auflösung des Hostnamens zur IP-Adresse wieder zur ursprünglichen
IP-Adresse zurückführt.

Ist dies nicht der Fall, würde ich von Software erwarten, dass sie den
Hostnamen ignoriert.

Grüße
Marc

[Herbert Kleebauer]

On 28.03.2016 06:21, Arno Welzel wrote:

> Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
> IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.

Du hast eine sehr seltsame Vorstellung von richtig und falsch.
Ich rufe die Telefonauskunft wegen der Nummer von Hans Meier
an und die Dame am Telefon sucht den richtigen Eintrag in
der Datenbank und gibt mir die Nummer. Leider hat zuvor
jemand in die Datenbank eine falsche Nummer eingetragen.
Ist die übermittelte Nummer nun richtig oder falsch? Ich mach
der Dame von der Auskunft ja keinen Vorwurf, sie hat alles
richtig gemacht, die Telefonnummer ist aber trotzdem falsch.

[Marc Haber]

Wie Dir nun in diesem Thread bald eine zweistellige Anzahl von Malen
nahegelegt wurde, gibt es einen Unterschied zwischen Forward und
Reverse DNS. Der Reverse DNS wird vom Inhaber der IP-Adresse; der
Forward DNS vom Inhaber der Domain gepflegt.

Nur wenn beide Einträge zueinander passen, kannst Du davon ausgehe,
dass der Inhaber der Domain damit einverstanden ist, dass der Inhaber
der IP-Adresse einen Namen aus der Domain für seine IP-Adresse
eingetragen hat.

Grüße
Marc

[Juergen P. Meier]

Peter J. Holzer <hjp-u...@hjp.at>:

> On 2016-03-27 13:15, Marc Haber <mh+usene...@zugschl.us> wrote:
>> Herbert Kleebauer <kl...@unibwm.de> wrote:
>>>Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>> by smtp.rzone.de (RZmta 37.22 OK)
>>> with ESMTP id f03a83s2Q9DW1x0
>>> for <??@unibwm.de>;
>>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>>>
>>>konnte ja nicht vom Absender gefälscht werden, er wurde ja
>>>vom Empfänger generiert.
>>
>> Genau, der hätte so von smtp.rzone.de nicht generiert werden dürfen
>> (weil der Forward nicht stimmt).
>
> Wo steht das? In RFC 5321 kommt da zwar ein "Domain" in der BNF vor,

Es ist nicht Teil des Standards. Aber es ist eine Sache der Vernunft
und Standardkonform umzusetzen.

Im Wikipedia findet man einen schoenen Artikel dazu:
https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS
und https://en.wikipedia.org/wiki/Anti-spam_techniques

> aber auch nach mehrmaligem Lesen von 4.4 finde ich keine Definition,
> welche Domain da stehen soll. Historisch war es ziemlich üblich, dass da
> das einfach das Ergebnis von gethostbyaddr(3) reingeworfen wurde. Nicht
> ideal, aber dass der MTA das nicht dürfte, halte ich für überzogen.

Der MTA sollte verifizeren ob die Domain, die der Sender von sich aus
behaupet zu sein auch zu diesem Sender passt.

[Juergen P. Meier]

Arno Welzel <use...@arnowelzel.de>:

> Herbert Kleebauer schrieb am 2016-03-27 um 22:41:
>
>> On 27.03.2016 20:50, Peter J. Holzer wrote:
>>
>>>>>> Der Header enthält eindeutig falsche Angaben:
>>>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>
>>> Wie bereits mehrmals gesagt: Du interpretierst Information in die
>>> Received-Zeile hinein, die da nicht drin steht. Die Received-Zeile ist
>>> nicht dafür da, rechtliche Eigentumsverhältnisse zu dokumentieren. Sie
>>> ist dafür da, zu dokumentieren, von welchem Host eine Mail empfangen
>>> wurde.
>>
>>
>> Auch deine vielen Worte ändern nichts daran, dass die "Received:"
>> Zeile falsche Angaben enthält.
>
> Zum Zeitpunkt der Zustellung waren die Angaben völlig korrekt, da ein
> PTR-Record für 212.227.8.37 existiert hat, der auf "targobank.de"
> aufgelöst hat.

Nein.

Die Falsche Angabe ist, dass die IP 212.227.8.37 zum Domainnamen
targobank.de gehoert. Das laesst sich ganz einfach durch einen
Forward-Check als Falsch verifizieren.

Dabei hat der MTA des OP versagt, was zur falschen Angabe im
Mailheader fuehrt.

Jeder MTA, der reverse-forward-verification beherrscht, kann die
Faelschung des PTR als solche erkennen und einen entsprechenden
Hinweis im Received-Header hinterlassen.

MTA Software aus diesem Jahrtausend kann das idR.

>> Wenn aus der IP Adresse der Name nicht aufgelöst werden kann,
>> wird entweder gar nichts oder "unknown" eingefügt.
>
> Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
> IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.

Aber targobank.de kann nicht zu dieser IP Aufgeloest werden.

Do'h

>> Diese Namensauflösung kann nun richtig oder falsch sein. Und
>> es spielt keine Rolle warum sie falsch ist (falscher DNS Eintrag
>> oder schlichter Programmierfehler oder auch Absicht), wenn sie
>> falsch ist, enthält die Received-Zeile falsche Angaben.
>
> Die Namensauflösung war nicht falsch. Es existierte ein entsprechender
> PTR-Record. Und ja - je nach Provider ist das trivial anzulegen.

Es fehlt immer noch der Vorwaertsbezug.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

Marc Haber <mh+usene...@zugschl.us>:
>
> Erwarte ich zuu viel, wenn ich hoffen würde, dass smtp.rzone.de nur
> hostnamen in seine Received-Header schreibt, bei denen der DNS
> vorwärte _und_ rückwärts passt?

Nein, damit erwartest du nicht zu viel. DAs sollte seit vielen Jahren
*Standard* sein bei Mailexchangern in oeffentlichen Datennetzen.

> Außerdem finde ich das sehr interessant, dass der Reverse eingetragen
> wurde. Normalerweise prüft 1&1 beim Eintrag von Reverse DNS Records ob
> der Forward passt.

Vielleicht wurde eine andre Schnittstelle als das Webfrontend
verwendet, ich kenne mich bei diesem Hoster nicht wirklich aus.

[Juergen P. Meier]

Thomas Hochstein <t...@inter.net>:

Evtl. ist Schlund auch selbst Opfer eines DNS Poisoning Angriffs geworden,
der das Anlegen dieses PTR ermoetlicht hat.

Aber das ist alles Spekulation.

[Stefan Froehlich]

On Mon, 28 Mar 2016 10:17:33 Marc Haber wrote:
> Der Reverse DNS wird vom Inhaber der IP-Adresse; der Forward DNS
> vom Inhaber der Domain gepflegt.

> Nur wenn beide Einträge zueinander passen, kannst Du davon
> ausgehe, dass der Inhaber der Domain damit einverstanden ist, dass
> der Inhaber der IP-Adresse einen Namen aus der Domain für seine
> IP-Adresse eingetragen hat.

Jupp. Mir ist allerdings schon einmal jemand untergekommen, der für
meinen forward-Lookup partout einen passenden reverse-Lookup sehen
wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
gleichen Host wäre das ein bisschen schwierig geworden.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Für den sympathischen Halunken von Welt - mästen mit Stefan!
(Sloganizer)

[Herbert Kleebauer]

On 28.03.2016 10:17, Marc Haber wrote:

>>>> >>>>> Der Header enthält eindeutig falsche Angaben:
>>>> >>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])

>>> Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
>>> IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.
>>
>> Du hast eine sehr seltsame Vorstellung von richtig und falsch.

> Wie Dir nun in diesem Thread bald eine zweistellige Anzahl von Malen
> nahegelegt wurde, gibt es einen Unterschied zwischen Forward und
> Reverse DNS. Der Reverse DNS wird vom Inhaber der IP-Adresse; der
> Forward DNS vom Inhaber der Domain gepflegt.

Was ändert das an der Tatsache, dass die Received Zeile eine
falsche Angabe enthält? Der Inhaber der IP-Adresse hat einen
falschen Domainnamen angegeben, der Mailempfangs-Server hat dies
falsche Angabe abgefragt und in den Header übernommen. Damit steht
diese falsche Angabe jetzt in der Received-Zeile und damit enthält
der Header eindeutig falsche Angaben. Ich weiß nicht worüber du
da noch diskutierst.

[Juergen P. Meier]

Stefan Froehlich <Stefan...@Froehlich.Priv.at>:

> Jupp. Mir ist allerdings schon einmal jemand untergekommen, der für
> meinen forward-Lookup partout einen passenden reverse-Lookup sehen
> wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
> gleichen Host wäre das ein bisschen schwierig geworden.

Darum prueft man ja auch nur die Client-IP Adresse, die auf einen PTR
aufloest (der kanonische Name deines Mailservers sozusagen) der
vorwaerts wiederum auf diese IP aufloesen muss.
Egal welche Domains du alles sonst noch auf dem Mailhost nutzt.

Das EHLO/HELO hingegen, das durchaus unterschiedlich je nach
Absenderdomain gesetzt werden kann (das meinst du vermutlich, oder?),
muss (sollte*) lediglich vorwaerts auf die IP aufloesen. Die IP muss
nicht rueckwaerts auf das HELO aufloesen, das waere falsch.

* Ein Spamfilter, der EHLO/HELO aufloesung auf die Client-IP prueft,
sollte nicht hart ablehnen nur weil dieser eine Check nicht stimmt, es
sollte vielmehr nur als eines von vielen Kriterien zur Spam-Erkennung
dienen.

[Marc Haber]

In der Tat. Welcher DNS-Server ist heute noch für Poisoning anfällig,
und glaubst Du ernsthaft, ein solcher DNS-Server würde mit der in so
einer Umgebung auftretenden Last fertig werden ohne in
Sekundenbruchteilen zu explodieren?

[Peter J. Holzer]

On 2016-03-27 19:39, Marc Haber <mh+usene...@zugschl.us> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>>On 2016-03-27 13:15, Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Herbert Kleebauer <kl...@unibwm.de> wrote:
>>>>Received: from mail.targobank.de (targobank.de [212.227.8.37])
>>>> by smtp.rzone.de (RZmta 37.22 OK)
>>>> with ESMTP id f03a83s2Q9DW1x0
>>>> for <??@unibwm.de>;
>>>> Sat, 26 Mar 2016 10:13:32 +0100 (CET)
>>>>
>>>>konnte ja nicht vom Absender gefälscht werden, er wurde ja
>>>>vom Empfänger generiert.
>>>
>>> Genau, der hätte so von smtp.rzone.de nicht generiert werden dürfen
>>> (weil der Forward nicht stimmt).
>>
>>Wo steht das? In RFC 5321 kommt da zwar ein "Domain" in der BNF vor,
>>aber auch nach mehrmaligem Lesen von 4.4 finde ich keine Definition,
>>welche Domain da stehen soll. Historisch war es ziemlich üblich, dass da
>>das einfach das Ergebnis von gethostbyaddr(3) reingeworfen wurde. Nicht
>>ideal, aber dass der MTA das nicht dürfte, halte ich für überzogen.
>
> Das hab ich nicht mit dem Hintergrund der formellen Standards gemeint.

Wer behauptet, dass etwas verboten ist ("darf nicht"), sollte auch
angeben können, wer dieses Verbot ausgesprochen hat, und welche
Legitimation derjenige hatte, irgendwas zu verbieten. "Marc Haber und
Juergen P. Meier haben dieses Verbot im März 2016 in
de.comm.software.mailserver ausgesprochen. Es gilt rückwirkend seit
1.1.2010" akzeptiere ich nicht als Antwort ;-).

Du hättest das auch anders formulieren können. Z.B. hättest Du schreiben
können, dass das heute state-of-the-art sei, einen
Reverse-und-Forward-Check wie von mir in
<slrnnfgaqo.l...@hrunkner.hjp.at> beschrieben durchzuführen,
und das mit dem Verhalten mehrerer weitverbreiteter MTAs (von Postfix
weiß ich, dass er das macht) belegen können.

Dagegen hätte ich nichts einzuwenden gehabt. Aber der Apell an die
deutsche (oder österreichische) Obrigkeitshörigkeit reizt meinen
Widerspruchsgeist.

hp

PS: Du brauchst mich nicht überzeugen, dass ein Check in beiden
Richtungen sinnvoll ist. Ich habe das z.B. 2006 in einem
qpsmtpd-Plugin implementiert (Allerdings zum Filtern, nicht
für die Received-Zeile)

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Mon, 28 Mar 2016 10:17:33 Marc Haber wrote:
>> Der Reverse DNS wird vom Inhaber der IP-Adresse; der Forward DNS
>> vom Inhaber der Domain gepflegt.
>
>> Nur wenn beide Einträge zueinander passen, kannst Du davon
>> ausgehe, dass der Inhaber der Domain damit einverstanden ist, dass
>> der Inhaber der IP-Adresse einen Namen aus der Domain für seine
>> IP-Adresse eingetragen hat.
>
>Jupp. Mir ist allerdings schon einmal jemand untergekommen, der für
>meinen forward-Lookup partout einen passenden reverse-Lookup sehen
>wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
>gleichen Host wäre das ein bisschen schwierig geworden.

Normalerweise guckt man reverse, findet einen Hostnamen, löst den
Hostnamen auf, und wenn man dann eine andere IP findet, schaut man ob
diese IP korrekt auf denselben Hostnamen zurück "passt". Dann erst
schreibt man den Hostnamen in received-Header.

Zu verlangen, dass Mail mit Absender aus example.org von einem Host
kommt, der auf example.org auflöst, ist natürlich Mumpitz.

[Marc Haber]

Herbert Kleebauer <kl...@unibwm.de> wrote:
>On 28.03.2016 10:17, Marc Haber wrote:
>
>>>>> >>>>> Der Header enthält eindeutig falsche Angaben:
>>>>> >>>>> Received: from mail.targobank.de (targobank.de [212.227.8.37])
>
>
>>>> Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
>>>> IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.
>>>
>>> Du hast eine sehr seltsame Vorstellung von richtig und falsch.
>
>
>> Wie Dir nun in diesem Thread bald eine zweistellige Anzahl von Malen
>> nahegelegt wurde, gibt es einen Unterschied zwischen Forward und
>> Reverse DNS. Der Reverse DNS wird vom Inhaber der IP-Adresse; der
>> Forward DNS vom Inhaber der Domain gepflegt.
>
>Was ändert das an der Tatsache, dass die Received Zeile eine
>falsche Angabe enthält?

Das ist IMO eine Implementierungs-Ungereimtheit[1] bei smtp.rzone.de.
Der Hostname hätte ohne passende Forward-Auflösung nicht in den
Received-Header geschrieben gehört.

Grüße
Marc

[1] diplomatisch ausgedrückt

[Arno Welzel]

Herbert Kleebauer schrieb am 2016-03-28 um 09:29:

> On 28.03.2016 06:21, Arno Welzel wrote:
>
>> Und genau das war zum Zeitpunkt der Zustellung nicht der Fall. Die
>> IP-Adresse 212.227.8.37 konnte sehr wohl zu "targobank.de" aufgelöst werden.
>
> Du hast eine sehr seltsame Vorstellung von richtig und falsch.
> Ich rufe die Telefonauskunft wegen der Nummer von Hans Meier
> an und die Dame am Telefon sucht den richtigen Eintrag in
> der Datenbank und gibt mir die Nummer. Leider hat zuvor
> jemand in die Datenbank eine falsche Nummer eingetragen.

Falsch - der Ablauf war genau umgekehrt: Du rufst bei der Auskunft an
und fragst nach dem Inhaber einer bestimmten Nummer, von der aus Dich
jemand angerufen hat. Und da wird dann ein Name genannt.

> Ist die übermittelte Nummer nun richtig oder falsch? Ich mach
> der Dame von der Auskunft ja keinen Vorwurf, sie hat alles
> richtig gemacht, die Telefonnummer ist aber trotzdem falsch.

Du hast aber keinen Namen, sondern eine Nummer.

[Arno Welzel]

Rein *technisch* ist die Angabe nicht falsch. Das wäre sie, wenn die
Software des Servers fehlerhaft arbeiten würde und statt der Angabe des
Nameservers irgendwas anderes eintragen würde.

[Peter J. Holzer]

On 2016-03-28 09:15, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Mon, 28 Mar 2016 10:17:33 Marc Haber wrote:
>> Der Reverse DNS wird vom Inhaber der IP-Adresse; der Forward DNS
>> vom Inhaber der Domain gepflegt.
>
>> Nur wenn beide Einträge zueinander passen, kannst Du davon
>> ausgehe, dass der Inhaber der Domain damit einverstanden ist, dass
>> der Inhaber der IP-Adresse einen Namen aus der Domain für seine
>> IP-Adresse eingetragen hat.
>
> Jupp. Mir ist allerdings schon einmal jemand untergekommen, der für
> meinen forward-Lookup partout einen passenden reverse-Lookup sehen
> wollte,

Um zum Forward-Lookup zu kommen, muss er erst einmal einen
Reverse-Lookup machen, denn am Anfang hat er nur eine IP-Adresse.
Wenn der Reverse-Lookup fehlschlägt, bekommt er nie einen Domainnamen,
auf den er ein Forward-Lookup machen könnte.

(Ja, man könnte den im EHLO übermittelten Namen verwenden. Das ist aber
nicht standardkonform - da steht eindeutig, "derived from TCP connection
not client EHLO")

Vom Anti-Spam-Standpunkt aus ist außerdem der Reverse-Lookup
aussagekräftiger als der Forward-Lookup: Domains sind billig und fast
unbegrenzt verfügbar. IP(v4)-Adressen hingegen nicht und ein beliebiges
Eintragen von PTR-Records ist in vielen Fällen (z.B. Bot an DSL oder
Kabel-Anschluss) nicht möglich.

> um Mails von mir zu akzeptieren. Ab der zweiten Domain am
> gleichen Host wäre das ein bisschen schwierig geworden.

Gar nicht. Der Standard-Algorithmus ermittelt einfach alle Paare, die
passen.

z.B.

Du bekommst eine Verbindung von 192.0.2.2

Im DNS gibt es (neben Milliarden anderen) folgende Einträge:

2.2.0.192.in-addr.arpa. PTR www.beispiel.at.
2.2.0.192.in-addr.arpa. PTR mail.example.com.
www.beispiel.at. A 198.51.100.23
www.beispiel.at. A 198.51.100.42
mail.example.com. A 192.0.2.2
mail.example.com. A 192.0.2.3
www.example.com. A 192.0.2.2
example.net. A 192.0.2.2


Du beginnst also bei der IP-Adresse 192.0.2.2 und ein Reverse-Lookup
liefert Dir zwei Domains:

www.beispiel.at.
mail.example.com.

Für beide suchst Du dann nach A-Records:

www.beispiel.at. A 198.51.100.23 (passt nicht)
www.beispiel.at. A 198.51.100.42 (passt auch nicht)

mail.example.com. A 192.0.2.2 (passt)
mail.example.com. A 192.0.2.3 (passt nicht)

Ergebnis ist in diesem Fall das Paar "mail.example.com. [192.0.1.2]"
Dass es noch zwei Domains (www.example.com. und example.net.) mit dem
gleichen A-Record gibt, ist nebensächlich, weil der Algorithmus
diese Domains nie findet.

Der Algorithmus kann 0, 1 oder mehrere Paare liefern. Wenn er mehr als
ein paar liefert, verwendet man irgendeines.

[Stefan Froehlich]

On Mon, 28 Mar 2016 12:18:24 Marc Haber wrote:
> >Mir ist allerdings schon einmal jemand untergekommen, der für
> >meinen forward-Lookup partout einen passenden reverse-Lookup sehen
> >wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
> >gleichen Host wäre das ein bisschen schwierig geworden.

> Zu verlangen, dass Mail mit Absender aus example.org von einem Host
> kommt, der auf example.org auflöst, ist natürlich Mumpitz.

Das habe ich ihm auch gesagt. Aber irgendwie meinen die anderen immer,
in der stärkeren Position zu sein (und meistens haben sie damit auch
recht).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Achten ist mein Ding. Stefan, so anständig wie die Ewigkeit.
(Sloganizer)

[Peter J. Holzer]

On 2016-03-28 11:01, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Mon, 28 Mar 2016 12:18:24 Marc Haber wrote:
>> >Mir ist allerdings schon einmal jemand untergekommen, der für
>> >meinen forward-Lookup partout einen passenden reverse-Lookup sehen
>> >wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
>> >gleichen Host wäre das ein bisschen schwierig geworden.
>
>> Zu verlangen, dass Mail mit Absender aus example.org von einem Host
>> kommt, der auf example.org auflöst, ist natürlich Mumpitz.
>
> Das habe ich ihm auch gesagt. Aber irgendwie meinen die anderen immer,
> in der stärkeren Position zu sein (und meistens haben sie damit auch
> recht).

Dir (oder mir) gegenüber vielleicht. Wenn der versucht, GMX oder UPC
oder Hetzner einzureden, dass sie für jede bei ihnen gehostete Domain
einen ausgehenden Mailserver mit passendem Hostnamen einzurichten haben,
wird er sehr schnell feststellen, dass die Länge seines Hebels gegen 0
tendiert.

[Thomas Hochstein]

Herbert Kleebauer schrieb:

> On 26.03.2016 12:00, Juergen P. Meier wrote:
>> Die Mail kam von einem System bei Schlund (1&1), das von
>> sich behauptet, "targobank.de" zu heissen.
>
> Soll das heißen, man kann auch den Angaben des nameservers
> nicht mehr vertrauen? Kann jeder für seine IP Adresse einen
> fremden Domainnamein eintragen lassen?

Wenn sein Provider das zulässt: freilich.

Daher gehört zur Überprüfung der Rückwärtsauflösung immer auch die
Vorwärtsauflösung dazu.

[...]
> Ablaufverfolgung beendet.

Und das sagt Dir (oder uns?) jetzt was?

-thh

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Mon, 28 Mar 2016 12:18:24 Marc Haber wrote:
>> >Mir ist allerdings schon einmal jemand untergekommen, der für
>> >meinen forward-Lookup partout einen passenden reverse-Lookup sehen
>> >wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
>> >gleichen Host wäre das ein bisschen schwierig geworden.
>
>> Zu verlangen, dass Mail mit Absender aus example.org von einem Host
>> kommt, der auf example.org auflöst, ist natürlich Mumpitz.
>
>Das habe ich ihm auch gesagt. Aber irgendwie meinen die anderen immer,
>in der stärkeren Position zu sein (und meistens haben sie damit auch
>recht).

Antispammer sind seit ca acht Jahren das größere Problem für E-Mail
als die Spammer.

[Marc Haber]

"Peter J. Holzer" <hjp-u...@hjp.at> wrote:

>On 2016-03-28 11:01, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Mon, 28 Mar 2016 12:18:24 Marc Haber wrote:
>>> >Mir ist allerdings schon einmal jemand untergekommen, der für
>>> >meinen forward-Lookup partout einen passenden reverse-Lookup sehen
>>> >wollte, um Mails von mir zu akzeptieren. Ab der zweiten Domain am
>>> >gleichen Host wäre das ein bisschen schwierig geworden.
>>
>>> Zu verlangen, dass Mail mit Absender aus example.org von einem Host
>>> kommt, der auf example.org auflöst, ist natürlich Mumpitz.
>>
>> Das habe ich ihm auch gesagt. Aber irgendwie meinen die anderen immer,
>> in der stärkeren Position zu sein (und meistens haben sie damit auch
>> recht).
>
>Dir (oder mir) gegenüber vielleicht. Wenn der versucht, GMX oder UPC
>oder Hetzner einzureden, dass sie für jede bei ihnen gehostete Domain
>einen ausgehenden Mailserver mit passendem Hostnamen einzurichten haben,
>wird er sehr schnell feststellen, dass die Länge seines Hebels gegen 0
>tendiert.

Andererseits verlangen gerade große Anbieter wie google, Hotmail,
Yahoo und United Internet ziemlich viel, bis sie Mail von einem
annehmen. Selbst von meinem bei Strato eingemieteten Server wird es
zunehmend schwerer, Mail loszuwerden - nicht wegen einem selbst,
sondern wegen der "Reputation" der Nachbarn. Toll, dass man darauf
einen so umwerfeneden Einfluss hat.

Der Betrieb eines eigenen Mailservers wird bis 2020 unmöglich sein.
Und zwar wegen der Antispammer.

[Florian Weimer]

* Marc Haber:

> Andererseits verlangen gerade große Anbieter wie google, Hotmail,
> Yahoo und United Internet ziemlich viel, bis sie Mail von einem
> annehmen. Selbst von meinem bei Strato eingemieteten Server wird es
> zunehmend schwerer, Mail loszuwerden - nicht wegen einem selbst,
> sondern wegen der "Reputation" der Nachbarn. Toll, dass man darauf
> einen so umwerfeneden Einfluss hat.
>
> Der Betrieb eines eigenen Mailservers wird bis 2020 unmöglich sein.
> Und zwar wegen der Antispammer.

Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben. Das
Thema Spam ist doch weitestgehend gelöst, niemand außer denjenigen,
die Mail-Infrastruktur betreiben, interessiert sich mehr dafür.

Interessant sind eher so solche Sachen wie Chat- und
Video-Integration, Präsenz, Zustellbenachrichtigungen, Prioritäten,
Verschlüsselung. Ich denke eher, daß es diese Dinge sein werden, die
E-Mail mittelfristig von offenem SMTP wegführen werden?

Verwendest Du die ISP-Resolver für Deine Mail-Server? Zugriff auf DNS
ist ein weiterer Aspekt, wo ich mit zukünftigen Einschränkungen
rechne (und zwar nicht für WWW-Sperren).

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>* Marc Haber:
>> Andererseits verlangen gerade große Anbieter wie google, Hotmail,
>> Yahoo und United Internet ziemlich viel, bis sie Mail von einem
>> annehmen. Selbst von meinem bei Strato eingemieteten Server wird es
>> zunehmend schwerer, Mail loszuwerden - nicht wegen einem selbst,
>> sondern wegen der "Reputation" der Nachbarn. Toll, dass man darauf
>> einen so umwerfeneden Einfluss hat.
>>
>> Der Betrieb eines eigenen Mailservers wird bis 2020 unmöglich sein.
>> Und zwar wegen der Antispammer.
>
>Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben.

Müssen sie ja gar nicht. Es reicht ja, wenn Mail, die nicht von einem
der Großprovider kommt, direkt im Spamverdacht landet, wie es z.B. bei
Gmail heute schon passiert, wenn die Mail aus dem falschen Strato-/24
kommt.

>Das
>Thema Spam ist doch weitestgehend gelöst, niemand außer denjenigen,
>die Mail-Infrastruktur betreiben, interessiert sich mehr dafür.

Ja, hauptsache es kommt kein Spam durch, die Anzahl false positives
ist weitgehend irrelevant.

>Verwendest Du die ISP-Resolver für Deine Mail-Server?

Ich glaube nein.

[Florian Weimer]

* Marc Haber:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>>* Marc Haber:
>>> Andererseits verlangen gerade große Anbieter wie google, Hotmail,
>>> Yahoo und United Internet ziemlich viel, bis sie Mail von einem
>>> annehmen. Selbst von meinem bei Strato eingemieteten Server wird es
>>> zunehmend schwerer, Mail loszuwerden - nicht wegen einem selbst,
>>> sondern wegen der "Reputation" der Nachbarn. Toll, dass man darauf
>>> einen so umwerfeneden Einfluss hat.
>>>
>>> Der Betrieb eines eigenen Mailservers wird bis 2020 unmöglich sein.
>>> Und zwar wegen der Antispammer.
>>
>>Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben.
>
> Müssen sie ja gar nicht. Es reicht ja, wenn Mail, die nicht von einem
> der Großprovider kommt, direkt im Spamverdacht landet, wie es z.B. bei
> Gmail heute schon passiert, wenn die Mail aus dem falschen Strato-/24
> kommt.

Wirf mal einen Blick in die Logs, ob Du Zustellung über IPv6 machst.
Dem Vernehmen nach ist das bei Gmail ziemlich kaputt implementiert,
IPv4 soll besser funktionieren.

>>Das Thema Spam ist doch weitestgehend gelöst, niemand außer
>>denjenigen, die Mail-Infrastruktur betreiben, interessiert sich mehr
>>dafür.
>
> Ja, hauptsache es kommt kein Spam durch, die Anzahl false positives
> ist weitgehend irrelevant.

Nun ja, seitdem ordentlich gewartete Filter Fehlerraten haben, die
besser sind als händisches Sortieren, frage ich, was man noch an
Verbesserungen erwarten kann.

Das Gmail-Problem (ob nun IPv6 oder nicht) ist ja nicht die Fehlerrate
oder der Spamfilter, sondern daß der Dienst im wesentlichen auf der
SMTP-Seite ungewartet ist.

>>Verwendest Du die ISP-Resolver für Deine Mail-Server?
>
> Ich glaube nein.

Dann wirst Du über kurz oder lang anfangen, ganz andere
Zustelleprobleme zu bekommen, weil die Hoster (und ISPs) anfangen,
direkten DNS-Verkehr zu sperren (insbesondere für Clients).

[Andreas Hartmann]

On 03/28/2016 at 07:20 AM Arno Welzel wrote:
> Andreas Hartmann schrieb am 2016-03-28 um 06:57:

>
>> On 03/26/2016 at 01:10 PM Marc Haber wrote:
>>> Herbert Kleebauer <kl...@unibwm.de> wrote:

>>>> Entscheidend sind aber eben obige Zeilen. Ein nslookup liefert
>>>>
>>>> nslookup 212.227.8.37
>>>>
>>>> Name: targobank.de
>>>> Address: 212.227.8.37
>>>
>>> Richtig. Aber:
>>
>> ?
>>
>> nslookup 212.227.8.37
>> Server: x
>> Address: x#53
>>
>> ** server can't find 37.8.227.212.in-addr.arpa.: NXDOMAIN
>>
>> Bei sämtlichen von mir geprüften DNS-Servern. Auch bei heise.
>
> Ja - JETZT, da die fraglichen Einträge offenbar gelöscht wuden. Aber vor
> etwa 2 Tagen war das anders.


dig +short NS targobank.de
ldnsie1p.e-i.net.
ldnsse2p.e-i.net.
ldnsie2p.e-i.net.
ldnsse1p.e-i.net.

In anderen Worten: die Domain targobank.de ist registriert und wird vom
oben genannten NS bedient.
Wie ist es möglich, dass sämtliche (nicht gekaperten) DNS-Server
weltweit Informationen für eine beliebige Domain ausliefern (in dem Fall
den Reverse-Lookup), welche nicht vom Domaininhaber selbst eingestellt
wurden?


Gruß,
Andreas

[Ralph Aichinger]

Florian Weimer <f...@deneb.enyo.de> wrote:
> Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben. Das
> Thema Spam ist doch weitestgehend gelöst, niemand außer denjenigen,
> die Mail-Infrastruktur betreiben, interessiert sich mehr dafür.

Hast du schon mal erlebt, wie lustig es ist, wenn du wegen irgendeines
gehackten Accounts auf Blacklists landest, und dann u.U. ein ganzes
Monat nicht an gmail oder Microsoft-Adressen rausschicken kannst?
Und da hilft dann unter umständen *gar nix* was du machen kannst, außer
einen anderen MX auf einer unberbrannten IP vorzuschalten?

> Verwendest Du die ISP-Resolver für Deine Mail-Server? Zugriff auf DNS
> ist ein weiterer Aspekt, wo ich mit zukünftigen Einschränkungen
> rechne (und zwar nicht für WWW-Sperren).

Damit rechne ich weniger. Immer mehr Leute haben einfach 8.8.8.8
im Resolver stehen.

/ralph

[Florian Weimer]

* Ralph Aichinger:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>> Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben. Das
>> Thema Spam ist doch weitestgehend gelöst, niemand außer denjenigen,
>> die Mail-Infrastruktur betreiben, interessiert sich mehr dafür.
>
> Hast du schon mal erlebt, wie lustig es ist, wenn du wegen irgendeines
> gehackten Accounts auf Blacklists landest, und dann u.U. ein ganzes
> Monat nicht an gmail oder Microsoft-Adressen rausschicken kannst?

Noch nicht. Ich war entweder klein genug, daß es keine gehackten
Accounts gab, oder groß genug, daß genügend erwartete Mail ankam.

> Und da hilft dann unter umständen *gar nix* was du machen kannst, außer
> einen anderen MX auf einer unberbrannten IP vorzuschalten?

Ich kann mir vorstellen, daß das ärgerlich ist. Mir behagt auch nicht,
wie das der Zentralisierung des Dienstes E-Mail Vorschub leistet.

>> Verwendest Du die ISP-Resolver für Deine Mail-Server? Zugriff auf DNS
>> ist ein weiterer Aspekt, wo ich mit zukünftigen Einschränkungen
>> rechne (und zwar nicht für WWW-Sperren).
>
> Damit rechne ich weniger. Immer mehr Leute haben einfach 8.8.8.8
> im Resolver stehen.

Das hätte wohl auch funktioniert, ich möchte das aus nachvollziehbaren
Gründen aber nicht. In meinem Fall hatte der Hoster einfach alle
DNS-Anfragen an die Nameserver für ISC.ORG blockiert, so daß ich weder
Postfächer dort erreichen konnte, und MODERATORS.ISC.ORG war auch tot.
Das fand ich nicht sonderlich lustig, und abstellen wollte der Support
die Blockade auch nicht.

[Juergen P. Meier]

Andreas Hartmann <andiha...@01019freenet.de>:

Vorsicht! Du verwechelst Forward mit Reverse.

DNS ist streng Hierarchisch, und fuer die Domain

targobank.de.

sind in der Reihenfolge jeweils folgende NS als *Autoritaet* zustaendig:

fuer . die Root-NS des IANA Namensraums des Internets
fuer de die NS des DeNIC
fuer targobank die NS von E-I.

Fuer den Reverse der IP-Adresse 212.227.8.37 hingegen, der ja
in DNS-Schreibweise 37.8.227.212.in-addr.arpa. lautet, sind das:

fuer . die root-NS des IANA Namensraums des Intereets
fuer arpa die root-NS des IANA Namensraums des Interenets*
fuer in-addr die root-NS des IANA Namensraums des Interenets
fuer 212 sind das die Nameserver des RIPE (ripe.net)
fuer 227 sind das bereits die NS von 1und1, weil das ein
kompletter /16 Netzblock ist, der an 1und1 vergeben wurde.
fuer 8 ebenso
und auch fuer 37.

* wurde vom US-Verteidigungsministerium fuer in-addr an die IANA delegiert

Ich hoffe du verstehst damit, warum das eine (vorwaertsaufloesung
eines Namens in eine IP-Adresse) mit dem anderen
(rueckwaertsaufloesung einer IP-Adresse in einen Namen) in der Regel
nichts mit einander zu tun haben.

Nur wer die Hoheit ueber den NAmensraum der Domain (vorwaerts) *und*
die Hoheit ueber den Namensraum der IP-Adresse (unterhalb von
in-addr.arpa) innehaelt, kann einen zirkulaer geschlossenen DNS
Eintrag anlegen, wo vorwaerts- und rueckwaerts jeweils auf den anderen
Eintrag aufgeloest werden.

Und nur der ist berechtigter Inhaber von IP *und* Domain.


Jeder Domaininhaber kann beliebig fremde IP-Adressen setzen
(Beispiel: blafasel.jors.net)
und jeder IP-Netzinhaber kann* beliebig fremde Domainnamen setzen
(Das beispiel hier war ja genau der Schlund-server dessen IP auf
"targobank.de" aufloest, obwohl der damit nichts zu tun hatte).

*fuer geeignete Werte von "kann", z.B. solange der Provider das nicht
verhindert.

[Arno Welzel]

Es ging aber um die IP-Adresse 212.227.8.37 und eine Domain.

> Wie ist es möglich, dass sämtliche (nicht gekaperten) DNS-Server
> weltweit Informationen für eine beliebige Domain ausliefern (in dem Fall
> den Reverse-Lookup), welche nicht vom Domaininhaber selbst eingestellt
> wurden?

Indem der Inhaber der IP-Adresse 212.227.8.37 einfach einen passenden
PTR-Record anlegt. Darauf hat der Domain-Inhaber rein technisch keinen
Einfluss.

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>n meinem Fall hatte der Hoster einfach alle
>DNS-Anfragen an die Nameserver für ISC.ORG blockiert, so daß ich weder
>Postfächer dort erreichen konnte, und MODERATORS.ISC.ORG war auch tot.
>Das fand ich nicht sonderlich lustig, und abstellen wollte der Support
>die Blockade auch nicht.

Darf ich fragen, wer dieser Hoster ist?

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>* Marc Haber:

>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>>Ich glaube nicht, daß die Antispammer solche Hebelwirkung haben.
>>
>> Müssen sie ja gar nicht. Es reicht ja, wenn Mail, die nicht von einem
>> der Großprovider kommt, direkt im Spamverdacht landet, wie es z.B. bei
>> Gmail heute schon passiert, wenn die Mail aus dem falschen Strato-/24
>> kommt.
>
>Wirf mal einen Blick in die Logs, ob Du Zustellung über IPv6 machst.
>Dem Vernehmen nach ist das bei Gmail ziemlich kaputt implementiert,
>IPv4 soll besser funktionieren.

Hab ich leider im Moment keine Statistiken und auch keine Möglichkeit
das auszuprobieren, so wichtig ist Gmail mir nicht.

>> Ja, hauptsache es kommt kein Spam durch, die Anzahl false positives
>> ist weitgehend irrelevant.
>
>Nun ja, seitdem ordentlich gewartete Filter Fehlerraten haben, die
>besser sind als händisches Sortieren, frage ich, was man noch an
>Verbesserungen erwarten kann.

Das macht das E-Mail-Hosting bei einem der "großen" immer
alternativloser. Gefallen muss mir dsa nicht.

>>>Verwendest Du die ISP-Resolver für Deine Mail-Server?
>>
>> Ich glaube nein.
>
>Dann wirst Du über kurz oder lang anfangen, ganz andere
>Zustelleprobleme zu bekommen, weil die Hoster (und ISPs) anfangen,
>direkten DNS-Verkehr zu sperren (insbesondere für Clients).

Für Hostingnetze sollte man das bitte unterlassen, dort sitzen auch
autoritative Nameserver.

[Thomas Hochstein]

Andreas Hartmann schrieb:

> Wie ist es möglich, dass sämtliche (nicht gekaperten) DNS-Server
> weltweit Informationen für eine beliebige Domain ausliefern (in dem Fall
> den Reverse-Lookup), welche nicht vom Domaininhaber selbst eingestellt
> wurden?

Weil der Domaininhaber mit dem Reverse-Lookup einer IP-Adresse nun
auch wirklich gar nichts zu tun hat. Wie in diesem Thread bereits
mehrfach geschildert.

[Andreas Hartmann]

Danke für die technische Erklärung bzw. den Status Quo.

> Nur wer die Hoheit ueber den NAmensraum der Domain (vorwaerts) *und*
> die Hoheit ueber den Namensraum der IP-Adresse (unterhalb von
> in-addr.arpa) innehaelt, kann einen zirkulaer geschlossenen DNS
> Eintrag anlegen, wo vorwaerts- und rueckwaerts jeweils auf den anderen
> Eintrag aufgeloest werden.
>
> Und nur der ist berechtigter Inhaber von IP *und* Domain.
>
>
> Jeder Domaininhaber kann beliebig fremde IP-Adressen setzen
> (Beispiel: blafasel.jors.net)
> und jeder IP-Netzinhaber kann* beliebig fremde Domainnamen setzen
> (Das beispiel hier war ja genau der Schlund-server dessen IP auf
> "targobank.de" aufloest, obwohl der damit nichts zu tun hatte).

Genau das ist das von mir angesprochene Problem! Diese Variante sollte
organisatorisch unterbunden werden! Niemand hindert die jeweils
Vergebenden miteinander zu "reden"! Dann würde die Nummer schon am
Anfang auffliegen.


Gruß,
Andreas

[Nomen Nescio]

Lall. Es macht keinen Sinn, die Flexibilität eines Systems für alle
einzuschränken, nur damit Laien sich nicht verwirrt fühlen.