Verursacher und damit Ansprechpartner ist auf jeden Fall der eMail-Provider.
Er ist es, der authentifizierte Benutzer durch seine Server abweisen läßt.
Um das mal klipp und klar aufzuzeigen, hier dieselben Spamlisten für dynamische Adressen anderer Provider:
T-Online:
http://www.senderbase.org/lookup?search_string=93.216.59.11
Email Reputation Poor
pbl.spamhaus.org Listed Vodafone:
http://www.senderbase.org/lookup?search_string=88.77.133.199
Email Reputation Poor
pbl.spamhaus.org Listed Wilhelm.tel:
http://www.senderbase.org/lookup?search_string=46.59.181.123
Email Reputation Poor
pbl.spamhaus.org Listed usw. usf.
Dieser Eintrag, also der bei pbl.spamhaus.org, ist völlig normal und es wäre ein Fehler in dieser Liste, wenn die angegebenen IPs dort
nicht eingetragen wären. Wie bereits zuvor erwähnt tut diese Liste nichts anderes, als angeben, daß die darin enthaltenen IPs dynamisch vergeben werden.
Die Konsequenz daraus, mit der eigenen IP dort eingetragen zu sein, ist folgende:
[email protected] möchte eine Nachricht an
[email protected] schicken.
Prinzipiell hat er die Möglichkeit, diese Mail ganz normal bei seinem eigenen Mail-Anbieter, also mail.gmx.net, einzuliefern und normalerweise wird er das auch tun, denn das Konzept der Crash-Mail ist zusammen mit dem Fido-Net untergegangen.
Technisch betrachtet hätte er aber auch die Möglichkeit, die Mail bei mx00.kundenserver.de abzukippen, dem Mail-eXchanger für online.de:
Code:
nslookup -type=mx online.de
online.de MX preference = 10, mail exchanger = mx01.kundenserver.de
online.de MX preference = 10, mail exchanger = mx00.kundenserver.de
oder auch jedem beliebigen anderen Mail Server.
In ersterem Fall würde er sich - heutzutage - im Regelfall beim Mailserver authentifizieren, in letzterem ginge das natürlich nicht, weil der Absender ja eben kein Kunde dort ist. Nichtsdestotrotz ist diese Vorgehensweise ursprünglich durchaus legitim gewesen. Beim Design des eMail-Transports erschien es noch nicht naheliegend, sich für den Mail
versand authentifizieren zu müssen, immerhin kommt man ja auf diesem Wege nicht an fremde Daten, sondern schickt nur selbstbestimmt eigene raus.
Nachdem sich das ArpaNet aber von einer mehr oder weniger geschlossenen Gesellschaft zu einem öffentlichen Netz entwickelte, kamen natürlich ein paar A*schgeigen irgendwann auf die Idee, diese "Lücke" im Konzept eMail auszunutzen, um ihren Müll (Spam) abzukippen, ohne die eigene Identität preisgeben zu müssen, denn wenn ich mich nicht authentifizieren muß, dann kann ich natürlich auch erdachte oder gefälschte eMail-Adressen verwenden.
Und genau hier kommt die pbl-Blockliste ins Spiel:
Weil sich die Identität des Absenders bei dynamischen IPs nur mit größerem Aufwand oder gar nicht bestimmen läßt und vor allem Strafmaßnahmen gegen diese IP ex post - also im Nachhinein - nicht greifen (Disconnect/Reconnect und der Spammer hat eine neue, ungeblockte), kann ein Mailserver-Betreiber durch Verwendung dieser Blockliste den Nutzern solcher IPs komplett untersagen, eMails abzuliefern, wenn sie dazu nicht einen Account des Betreibers als Absendeadresse verwenden.
Bei den höherwertigen statischen IPs hingegen gilt nach wie vor der Vertrauensvorschuß, da man diese auch noch im Nachhinein über viel giftigere Blocklisten aussperren kann, wenn sie sich als Spam-Schleuder entpuppen. Der Absender wird die statische IP ja nicht durch Disconnect/Reconnect einfach so wieder los ...
Zusammengefaßt läßt sich sagen:
Die PBL trifft - solange die Mailserver-Betreiber ihre Konfiguration im Griff haben - nur solche Benutzer, die versuchen, ihre eMail an ihrem eigenen eMail-Provider vorbei direkt beim Mail-Server des Empfängers oder einem dritten Mail-Server abzukippen bzw. Benutzer, die einen eigenen Mailserver auf einer dynamischen IP betreiben.
Normale MUAs (Mail User Agents) wie The Bat, AKMail, PMMail, Pegasus Mail, Outlook etc. pp. sind hierzu aber gar nicht in der Lage. Versehentlich kann das eigentlich nur mit antiken oder rückständigen Linux-Distributionen passieren, bei denen ein MUA aus Software für MTA/MDA (Mail Transfer Agent/Mail Delivery Agent) und einem Reader zusammengeschustert wurde, also z.B. mutt+sendmail+fetchmail.
Daraus folgt:
Wenn eine eMail ordnungsgemäß über den Mail-Server des eMail-Providers eingeliefert, aber trotzdem nur wegen des PBL-Eintrags nicht ausgeliefert wird, dann ist der nicht ausliefernde eMail-Provider der Ansprechpartner.
Ist es hingegen nur aufgrund des PBL-Eintrages schon gar nicht möglich, die Mail beim eigenen eMail-Provider einzuliefern, dann ist der eigene eMail-Provider der Ansprechpartner.
Der Internet-Provider ist nur dann der richtige Ansprechpartner, wenn die eigene
statische IP auf der PBL steht oder aber, wenn IPs - auch dynamische - auf z.B. den Listen
- bl.spamcop.net
- cbl.abuseat.org
stehen.
Auf diesen Listen landen nur tatsächliche Zombies und Spamschleudern, also kompromittierte Rechner, leider aber eben auch solche mit dynamischen IPs, so daß man u.U. mit einem sauberen Rechner eine versaute IP "erben" kann. Von diesen Listen kann man sich zwar auch ohne Hilfe durch den Internet-Provider mit einem simplen Klick löschen lassen, das nutzt aber praktisch nur dann auf Dauer etwas, wenn man noch einen IPv4-Zugang hat und die IP somit auch über Tage und Wochen behält. Der Zombie/Spammer ist aber immer noch infiziert, schleudert seine Pest weiter raus und versaut somit eine IP nach der anderen, bei den häufig wechselnden IPs beim CGN/DS-lite ist es also nur eine Frage der Zeit, bis man wieder eine IP von der Spam-/Virenschleuder erbt.
Hier kann dann dauerhaft nur der Internet-Provider helfen, indem er den Volltrottel vom Netz nimmt.
