IP-Adressen von Unitymedia auf eMail-Blockliste

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.
M@rtin
Übergeordneter Verstärkerpunkt
Beiträge: 572
Registriert: 27.05.2013, 19:38

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von M@rtin » 14.10.2013, 19:14

Bin auch davon betroffen. Bis Sonntag früh funktionierte das noch, seit spätestens heute Nacht nicht mehr.

Bernie72
erfahrener Kabelkunde
Beiträge: 99
Registriert: 20.12.2009, 18:08

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von Bernie72 » 14.10.2013, 19:45

Willkommen im Club!
Bitte ein Ticket bei UM eröffnen!

Gruß

Bernie
2play Comfort 120
(eigene) Fritz!Box 6490
Technisat DigiCorder ISIO C mit
- Alphacrypt-Classic mit Sky Welt/BuLi/Sport/HD
- UM HD-Modul mit HD Option (TV-Start)

nobody843
Kabelneuling
Beiträge: 10
Registriert: 02.10.2013, 00:11

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von nobody843 » 14.10.2013, 20:00

http://www.senderbase.org/lookup?search ... 192.195.22
da wird sich so schnell nichts ändern.
Ob nun ein wirklicher Spammer bei KabelBW hockt, und, die den nicht bremsen können, oder, ob die adressen einfach weil es ein dial-up/consumer bereich ist:
http://www.spamhaus.org/pbl/query/PBL337178

Der Schuldige ist web.de
Dort müsst Ihre Eure Tickets eröffen, 3.99/Anruf.

Bernie72
erfahrener Kabelkunde
Beiträge: 99
Registriert: 20.12.2009, 18:08

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von Bernie72 » 14.10.2013, 20:08

Sehe ich anders.
Die IPs müssen von der Blacklist runter!!!

Man kann mache eMail-Empfänger nicht erreichen, da auch eingehende Mails geblockt werden, so z. B. bei Arcor.
Ich kann also zur Zeit niemanden bei Arcor anmailen :wand:

Klar kann man bei GMX/Web.de ein Ticket eröffnet, schadet nix, habe ich auch gemacht.
Behebt aber die Ursache nicht!

Gruß

Bernie
2play Comfort 120
(eigene) Fritz!Box 6490
Technisat DigiCorder ISIO C mit
- Alphacrypt-Classic mit Sky Welt/BuLi/Sport/HD
- UM HD-Modul mit HD Option (TV-Start)

nobody843
Kabelneuling
Beiträge: 10
Registriert: 02.10.2013, 00:11

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von nobody843 » 14.10.2013, 20:45

Falsch. Ausser Du betreibst Deinen eigenen mailserver hinter einer dieser KabelBW adressen.
Ein mailserver, der ein Mail beurteilt, das ankommt, der wird, und sollte nur die IP Adresse ankucken, die Gerade mit ihm kommuniziert, nicht aber, das, was in der kette der mails vorher geschah (und wenn, dann hat das einen geringeren Stellenwert, denn das kann und ist oft gefälscht, zumindest nicht zuverlässig.

Schickst Du eine mail an Deinen Provider, dann ist die einzige email adresse, die die antispamkontrolle des empfängers prüft, die IP Adresse des smtp servers Deines providers, nicht jedoch Deine.

Dial-UP/Consumer IPs die nicht statisch sind gehören immer auf eine blacklist (zumindest auf eine DUL-Blacklist), egal, ob von dort spam kommt, oder nicht.

Edit: im übrigen ist es ja der email provider er aufgrund einer liste ein mail ablehnt - es ist nicht die blacklist, und auch nicht kabelBW. Das müsste der nicht machen. WEB.de könnte auch weichere Maßnahmen ergreifen. Z.B. gibt es punkte-systeme, und, erst ab XXX punkten lehne ich emails ab (wenn auch nicht von eigenen kunden). Ein Tag der mail als möglichen SPAM das wäre ja noch verständlich, nicht aber, eine Ablehnung.

NoGi
Übergeordneter Verstärkerpunkt
Beiträge: 569
Registriert: 08.11.2012, 10:59
Wohnort: Metropolregion Rhein-Neckar

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von NoGi » 14.10.2013, 22:35

nobody843 hat geschrieben:Falsch. Ausser Du betreibst Deinen eigenen mailserver hinter einer dieser KabelBW adressen.
Ein mailserver, der ein Mail beurteilt, das ankommt, der wird, und sollte nur die IP Adresse ankucken, die Gerade mit ihm kommuniziert, nicht aber, das, was in der kette der mails vorher geschah (und wenn, dann hat das einen geringeren Stellenwert, denn das kann und ist oft gefälscht, zumindest nicht zuverlässig.

Schickst Du eine mail an Deinen Provider, dann ist die einzige email adresse, die die antispamkontrolle des empfängers prüft, die IP Adresse des smtp servers Deines providers, nicht jedoch Deine.

Dial-UP/Consumer IPs die nicht statisch sind gehören immer auf eine blacklist (zumindest auf eine DUL-Blacklist), egal, ob von dort spam kommt, oder nicht.
Also, entweder hast du dich unglücklich ausgedrückt, oder du liegst völlig daneben:

Ich habe ein EMail Konto bei GMX, eins bei Google und eins bei KabelBW. Eingeliefert wird von meinem Rechner
über Thunderbird. Dabei nutze ich als KabelBW Kunde natürlich die IPv4 Adresse die mir KabelBW
zugeteilt hat.

Ich würde mir sehr verbitten, dass GMX Email, die ich doppelt identifiziert dort einliefere, blockt.
(GMX authentifiziert den Benutzer und lässt auch nur Mail zu in der der Envelope From: Eintrag ein Name (Alias) dieses Benutzers ist)

Bei Google hab ich das Problem nicht, da dort die Email per IPv6 eingeliefert wird.

EDIT: Hab gerade gesehen, dass du deinen Beitrag editiert hast.
Ein Provider hat EMail seiner eigenen authentifizierten Kunden in keinem Fall abhängig von der IP zu blocken.

-NoGi
Zuletzt geändert von NoGi am 14.10.2013, 22:41, insgesamt 1-mal geändert.

nobody843
Kabelneuling
Beiträge: 10
Registriert: 02.10.2013, 00:11

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von nobody843 » 14.10.2013, 22:38

Weiss nicht, ob ein missverständnis vorliegt, aber WEB.de macht genau das:
blockt emails von kunden, die sich per benutzername + passwort authentifizieren und eine @web.de Adresse (nämlich die eigene) als absender haben.

und, ja, google und jeder andere macht das nicht.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 04:14

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 ... .216.59.11
Email Reputation Poor
pbl.spamhaus.org Listed


Vodafone:
http://www.senderbase.org/lookup?search ... 77.133.199
Email Reputation Poor
pbl.spamhaus.org Listed


Wilhelm.tel:
http://www.senderbase.org/lookup?search ... 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:
Fritz.Mueller@gmx.de möchte eine Nachricht an Max.Mustermann@online.de 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: Alles auswählen

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 Mailversand 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.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Bernie72
erfahrener Kabelkunde
Beiträge: 99
Registriert: 20.12.2009, 18:08

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von Bernie72 » 15.10.2013, 09:14

Danke für die ausführlichen Erläuterungen.
Also, wenn ich alles zusammenfasse, ist UM nicht schuld, da die IPs aller gängigen Provider auf der Blacklist stehen.

Da ich mich bei der eMail-Ablieferung (mitttels Thunderbird) ordentlich bei GMX anmelde, müsste die eMail auch veschickt werden.
Ich mache das ganze ja nicht anonym oder bei einem dritten Anbieter.

Seltsamerweise muss bei GMX aber ein Zusammenhang bestehen, da ich z. B. über Mobilfunk weiterhin eMails von meinem Account versenden kann.
Also das Zusammenspiel meiner eMail-Adresse mit der IP von UM führt zur Abweisung.
Ich habe 3 eMail-Konten bei GMX und habe bei allen 3 das gleiche Problem.

Störung bei GMX läuft.
Alternative: Einen anderen eMail-Provider suchen, oder?

Gruß

Bernie
2play Comfort 120
(eigene) Fritz!Box 6490
Technisat DigiCorder ISIO C mit
- Alphacrypt-Classic mit Sky Welt/BuLi/Sport/HD
- UM HD-Modul mit HD Option (TV-Start)

NoGi
Übergeordneter Verstärkerpunkt
Beiträge: 569
Registriert: 08.11.2012, 10:59
Wohnort: Metropolregion Rhein-Neckar

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von NoGi » 15.10.2013, 10:43

Bernie72 hat geschrieben:Danke für die ausführlichen Erläuterungen.
Also, wenn ich alles zusammenfasse, ist UM nicht schuld, da die IPs aller gängigen Provider auf der Blacklist stehen.

Da ich mich bei der eMail-Ablieferung (mitttels Thunderbird) ordentlich bei GMX anmelde, müsste die eMail auch veschickt werden.
Ich mache das ganze ja nicht anonym oder bei einem dritten Anbieter.
[schnippel]
Störung bei GMX läuft.
Alternative: Einen anderen eMail-Provider suchen, oder?
Ich würde Spacerats super Erklärung noch weiter verstärken:

Ein E-Mail Provider der bereits per IP-Adresse blockt hat ein Rad ab!
Er hat erst zu prüfen, ob sich ein eigener Benutzer anmelden möchte und danach zu entscheiden
ob er die Einlieferung verweigert. (Stichwort: Benutzerkonto ist als Spammer bekannt, oder versucht Unmengen von Mail abzusetzen)

Verbindet sich ein anderer Mail-Server und versucht Mail an zu liefern kann er das über eine Whitelist abhandeln oder
eben auch durch Authentifizierung.

Zu deinen Problemen mit GMX:
Es gibt das Schweizer Armeemesser für SMTP. Damit kann man wunderbar herausfinden wo es klemmt:

Code: Alles auswählen

gio3:~ # swaks --to NoGi@kabelbw.de --from NoGi@NoGi.de --server smtp.gmx.de --protocol ESMTPS --auth-user NoGi@NoGi.de -ap SagIchNicht
=== Trying smtp.gmx.de:25...
=== Connected to smtp.gmx.de.
<-  220 gmx.com (mrgmx001) Nemesis ESMTP Service ready
 -> EHLO gio3.NoGi.de
<-  250-gmx.com Hello gio3.NoGi.de [GuteIPv4Adresse]
<-  250-SIZE 69920427
<-  250-AUTH LOGIN PLAIN
<-  250 STARTTLS
 -> STARTTLS  
<-  220 OK   
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256    
=== TLS no local certificate set  
=== TLS peer DN="/C=DE/O=1&1 Mail & Media GmbH/OU=GMX/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=mail.gmx.net" 
 ~> EHLO gio3.NoGi.de 
<~  250-gmx.com Hello gio3.NoGi.de [GuteIPv4Adresse] 
<~  250-SIZE 69920427    
<~  250 AUTH LOGIN PLAIN   
 ~> AUTH LOGIN  
<~  334 VXNlcmxxxWU6 
 ~> aW1wYXJvLml0YWxpYWxxxGdpcmFyZGlzLmRl  
<~  334 UGFzcxxxcmQ6 
 ~> V3Nkxxx3NDc= 
<~  235 Authentication succeeded 
 ~> MAIL FROM:<NoGi@NoGi.de>             
<~  250 Requested mail action okay, completed  
 ~> RCPT TO:<NoGi@kabelbw.de>  
<~  250 OK   
 ~> DATA
<~  354 Start mail input; end with <CRLF>.<CRLF> 
 ~> Date: Tue, 15 Oct 2013 09:49:27 +0200
 ~> To: NoGi@kabelbw.de  
 ~> From: NoGi@NoGi.de  
 ~> Subject: test Tue, 15 Oct 2013 09:49:27 +0200   
 ~> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/ 
 ~>   
 ~> This is a test mailing 
 ~> 
 ~> . 
<~  250 Requested mail action okay, completed: id=0M8NBi-1VjVpN3xxx-00vy1W
 ~> QUIT  
<~  221 gmx.com Service closing transmission channel   
=== Connection closed with remote host.

Das Teil läuft auch unter Windows wenn man sich Perl und die entsprechenden Module installiert.

-NoGi

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 13:25

Mir ist im Thread aufgefallen, daß anscheinend mail.gmx.com als Mailserver eingetragen wurde.

Korrekt ist aber eigentlich und unabhängig von der Domain in der eigenen Adresse nur mail.gmx.net.
mail.gmx.de funktioniert mit Einschränkungen zwar auch, aber die Server-Zertifikate decken nur gmx.net ab, gmx.de funktioniert also spätestens dann nicht mehr, wenn man eine sichere Authentifizierung verwendet (In diesem Fall muß der Client den Server ablehnen, da sich dieser nicht "ausweisen" kann).
Siehe dazu auch diese Zeile aus NoGis Log:
=== TLS peer DN="/C=DE/O=1&1 Mail & Media GmbH/OU=GMX/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=mail.gmx.net"

Schaue ich mir die Website gmx.com mal an, dann sieht man auch, daß GMX da was anderes drauf laufen hat.

Auch reagieren da völlig andere Server:
Name: mail.gmx.com
Addresses: 212.227.17.174
212.227.17.184


Name: mail.gmx.net
Addresses: 212.227.17.190
212.227.17.168

Aliases: mail.gmx.de

Mit gmx.fr, gmx.es, gmx.co.uk landet man übrigens auf demselben Server wie mit gmx.com, aber eben niemals auf dem dt. Server mit der Adresse gmx.net

gmx.com hat auch ein eigenes Zertifikat:
>15.10.2013, 13:19:18: SEND - Zertifikat S/N: 10158C0E09864F4D06DD9977D0AA18B7, Algorithmus: RSA (2048 Bits), ausgestellt von 23.09.2013 bis 03.10.2015 23:59:59, für 1 Host(s): mail.gmx.com.
>15.10.2013, 13:19:18: SEND - Besitzer: US, Pennsylvania, Chesterbrook, 1&1 Mail & Media Inc., mail.gmx.com.
>15.10.2013, 13:19:18: SEND - Aussteller: US, Thawte, Inc., Thawte SSL CA.
>15.10.2013, 13:19:18: SEND - Root: US, thawte, Inc., Certification Services Division, (c) 2006 thawte, Inc. - For authorized use only, thawte Primary Root CA
vs gmx.net:
>15.10.2013, 13:08:10: SEND - Zertifikat S/N: E4E92A540EF0F5CB, Algorithmus: RSA (2048 Bits), ausgestellt von 21.08.2013 08:32:02 bis 26.08.2016 23:59:59, für 1 Host(s): mail.gmx.net.
>15.10.2013, 13:08:10: SEND - Besitzer: DE, 1&1 Mail & Media GmbH, GMX, Rhineland-Palatinate, Montabaur, server-certs@1und1.de, mail.gmx.net.
>15.10.2013, 13:08:10: SEND - Aussteller: DE, T-Systems International GmbH, T-Systems Trust Center, NRW, 57250, Netphen, Untere Industriestr. 20, TeleSec ServerPass DE-1.
>15.10.2013, 13:08:10: SEND - Root: DE, Deutsche Telekom AG, T-TeleSec Trust Center, Deutsche Telekom Root CA 2
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 13:50

Bernie72 hat geschrieben:Danke für die ausführlichen Erläuterungen.
Also, wenn ich alles zusammenfasse, ist UM nicht schuld, da die IPs aller gängigen Provider auf der Blacklist stehen.
Im Idealfall alle dynamisch vergebenen IPs weltweit.
Bernie72 hat geschrieben:Seltsamerweise muss bei GMX aber ein Zusammenhang bestehen, da ich z. B. über Mobilfunk weiterhin eMails von meinem Account versenden kann.
Also das Zusammenspiel meiner eMail-Adresse mit der IP von UM führt zur Abweisung.
Ich habe 3 eMail-Konten bei GMX und habe bei allen 3 das gleiche Problem.
Nun, wie lauten denn Deine Einstellungen in Thunderbird?

Und womit verschickst Du "über Mobilfunk" die eMails? Mit demselben Thunderbird oder mit einer App auf dem SmartPhone?

Du könntest natürlich auch Deine IP hier nachsehen:
http://www.senderbase.org/lookup/ip?sea ... .193.34.10
(109.193.34.10 durch Deine IP ersetzen), um festzustellen, ob diese auf mehr Listen erscheint als nur der PBL.

Die o.g. IP erscheint auf mehreren dieser Listen und ist mit einem Trojaner infiziert:
IP Address 109.193.34.10 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet.
It was last detected at 2013-10-14 14:00 GMT (+/- 30 minutes), approximately 21 hours, 30 minutes ago.
This IP is infected (or NATting for a computer that is infected) with the kelihos spambot. In other words, it's participating in a botnet.


109.193.34.10 listed in bl.spamcop.net (127.0.0.2)
If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 21 hours.

Causes of listing
System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)

Aus diesen Listen kann man sich selber austragen, was man natürlich erst tun sollte, wenn das Problem beseitigt wurde.

In einer idealen Welt würde der Internet-Provider den Anschluß kappen, der am 14.10.2013 um 14:00 Uhr Greenwich Mean Time die IP 109.193.34.10 hatte.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

NoGi
Übergeordneter Verstärkerpunkt
Beiträge: 569
Registriert: 08.11.2012, 10:59
Wohnort: Metropolregion Rhein-Neckar

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von NoGi » 15.10.2013, 14:15

SpaceRat hat geschrieben:Korrekt ist aber eigentlich und unabhängig von der Domain in der eigenen Adresse nur mail.gmx.net.
mail.gmx.de funktioniert mit Einschränkungen zwar auch, aber die Server-Zertifikate decken nur gmx.net ab, gmx.de funktioniert also spätestens dann nicht mehr, wenn man eine sichere Authentifizierung verwendet (In diesem Fall muß der Client den Server ablehnen, da sich dieser nicht "ausweisen" kann).
Siehe dazu auch diese Zeile aus NoGis Log:
=== TLS peer DN="/C=DE/O=1&1 Mail & Media GmbH/OU=GMX/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=mail.gmx.net"
Hmmm..., meinst du jetzt dass der Client den Server auf dem er einliefern will ablehnen muss?

Selbst wenn ich swaks mit --tls-verify starte kann ich auf allen GMX Adressen einliefern.
Dabei macht es keinen Unterschied ob ich über Port 25 oder Port 465 starte.

1.) Deutschland mit Zeritifikatprüfung
=== Trying smtp.gmx.de:465...
=== Connected to smtp.gmx.de.
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/C=DE/O=1&1 Mail & Media GmbH/OU=GMX/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=mail.gmx.net"
<~ 220 gmx.com (mrgmx103) Nemesis ESMTP Service ready
~> EHLO gio3.NoGi.de

2.) Fronkreisch avec verification du certificat
=== Trying smtp.gmx.fr:465...
=== Connected to smtp.gmx.fr.
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/C=US/ST=Pennsylvania/L=Chesterbrook/O=1&1 Mail & Media Inc./CN=mail.gmx.com"
<~ 220 gmx.com (mrgmxus002) Nemesis ESMTP Service ready
~> EHLO gio3.NoGi.de

Beide melden sich mit " 220 gmx.com (xxxxxxxx) Nemesis ESMTP Service ready
Lediglich an den Rechnernamen MailRelayGMX103 und MailRelayGMXUS002
kann man vermuten wo die Relais stehen.

-NoGi

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 14:54

NoGi hat geschrieben:
SpaceRat hat geschrieben:Korrekt ist aber eigentlich und unabhängig von der Domain in der eigenen Adresse nur mail.gmx.net.
mail.gmx.de funktioniert mit Einschränkungen zwar auch, aber die Server-Zertifikate decken nur gmx.net ab, gmx.de funktioniert also spätestens dann nicht mehr, wenn man eine sichere Authentifizierung verwendet (In diesem Fall muß der Client den Server ablehnen, da sich dieser nicht "ausweisen" kann).
Siehe dazu auch diese Zeile aus NoGis Log:
=== TLS peer DN="/C=DE/O=1&1 Mail & Media GmbH/OU=GMX/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=mail.gmx.net"
Hmmm..., meinst du jetzt dass der Client den Server auf dem er einliefern will ablehnen muss?
Ja, denn dieser kann sich nicht richtig ausweisen.

Diese Situation entspricht folgendem Warnhinweis im Web-Browser beim Versuch, eine sichere Web-Site zu erreichen:
Bild

Oder übersetzt:
"Beim Versuch, auf http://www.postbank.de zuzugreifen, haben Sie einen Server erreicht, der sich pbank.phishing.cn nennt. Dies kann an einer fehlerhaften Konfiguration liegen, jedoch auch schwerwiegendere Ursachen haben. Möglicherweise versucht ein Hacker, Sie auf eine gefälschte und potenziell gefährliche Version von http://www.postbank.de zu locken."

Tatsache ist ja, daß Du versuchst, mail.gmx.de zu erreichen, sich der Server aber nicht für diese Domain ausweisen kann, sondern nur für mail.gmx.net. In diesem Fall ist es jetzt zwar nicht so, aber prinzipiell könnte sich hinter mail.gmx.de auch ein Logins sammelnder Rechner in China verbergen.
Da trotz fehlerhaftem Zertifikat fortzufahren führt den gesamten Sinn und Zweck von Zertifikaten ad absurdum.

Du kannst ja mal über die hosts Datei folgenden Fehler injizieren:

213.165.67.120 mail.gmx.de

In Wirklichkeit steckt hinter der IP der Mail-Server für web.de ...
Wenn der Login erst durch web.de nach Absenden des fehlerhaften Login-Daten abgebrochen wird, statt schon beim fehlerhaften Zertifikat durch Deinen Client, dann hätte Dein Client Deine Credentials auch jedem Hinz und Kunz im Internet geschickt.
NoGi hat geschrieben:Selbst wenn ich swaks mit --tls-verify starte kann ich auf allen GMX Adressen einliefern.
Tjor, hoffentlich hält das Dein Mail-Client nicht so.
Zuletzt geändert von SpaceRat am 15.10.2013, 15:14, insgesamt 2-mal geändert.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 15:02

Übrigens bedeutet das, daß Du swaks auch gepflegt in die Tonne kloppen kannst.

Da sich das Teil völlig anders als ein brauchbarer Mail-Client verhält (Er weist ja nicht einmal auf das fehlerhafte Zertifikat hin), kann man damit eben auch keine Verbindungen zu einem Mail-Server austesten.

Das stünde bei einem guten Mail-Client (Hier: The Bat!) im Log:

15.10.2013, 14:59:07: FETCH - Verbinde mit POP3-Server pop.gmx.de auf Port 110
15.10.2013, 14:59:07: FETCH - Einleitung TLS-Handshake
>15.10.2013, 14:59:07: FETCH - Zertifikat S/N: 429122A6486E892FBE9D106E7B3E8074, Algorithmus: RSA (2048 Bits), ausgestellt von 24.04.2013 bis 24.04.2015 23:59:59, für 1 Host(s): pop.gmx.net.
>15.10.2013, 14:59:07: FETCH - Besitzer: DE, Rhineland-Palatinate, Montabaur, 1&1 Mail & Media GmbH, pop.gmx.net.
>15.10.2013, 14:59:07: FETCH - Aussteller: US, Thawte, Inc., Thawte SSL CA.
>15.10.2013, 14:59:07: FETCH - Root: US, thawte, Inc., Certification Services Division, (c) 2006 thawte, Inc. - For authorized use only, thawte Primary Root CA
!15.10.2013, 14:59:07: FETCH - TLS-Handshakefehler. Keine Übereinstimmung zwischen Hostname ("pop.gmx.de") und Zertifikat.

PS: Überhaupt ist swaks nutzlos, weil ein brauchbarer Mail-Client ein eigenes, aussagekräftiges Log führt.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 15:27

Und weil ich es vorgeschlagen habe, hier mal das Ergebnis, wenn man die Mails von pop.gmx.net abholen möchte, dabei aber pop3.web.de erreicht:

15.10.2013, 15:22:41: FETCH - Empfange Nachrichten
15.10.2013, 15:22:41: FETCH - Verbinde mit POP3-Server pop.gmx.net auf Port 110
15.10.2013, 15:22:41: FETCH - Einleitung TLS-Handshake
>15.10.2013, 15:22:41: FETCH - Zertifikat S/N: 71884804F0BDB9FD185F87D329F2CBF0, Algorithmus: RSA (2048 Bits), ausgestellt von 26.07.2013 bis 13.08.2014 23:59:59, für 1 Host(s): pop3.web.de.
>15.10.2013, 15:22:41: FETCH - Besitzer: DE, Rhineland-Palatinate, Montabaur, 1&1 Mail & Media GmbH, WEB.DE, pop3.web.de.
>15.10.2013, 15:22:41: FETCH - Aussteller: US, Thawte, Inc., Thawte SSL CA.
>15.10.2013, 15:22:41: FETCH - Root: US, thawte, Inc., Certification Services Division, (c) 2006 thawte, Inc. - For authorized use only, thawte Primary Root CA
!15.10.2013, 15:22:41: FETCH - TLS-Handshakefehler. Keine Übereinstimmung zwischen Hostname ("pop.gmx.net") und Zertifikat.

Mein Client würde also, so wie es sich gehört, keine Credentials an einen Server schicken, der sich nicht als der Server ausweisen kann, den ich zu erreichen versuche!

NoGi
Übergeordneter Verstärkerpunkt
Beiträge: 569
Registriert: 08.11.2012, 10:59
Wohnort: Metropolregion Rhein-Neckar

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von NoGi » 15.10.2013, 17:14

SpaceRat hat geschrieben:Übrigens bedeutet das, daß Du swaks auch gepflegt in die Tonne kloppen kannst.

Da sich das Teil völlig anders als ein brauchbarer Mail-Client verhält (Er weist ja nicht einmal auf das fehlerhafte Zertifikat hin), kann man damit eben auch keine Verbindungen zu einem Mail-Server austesten.

Das stünde bei einem guten Mail-Client (Hier: The Bat!) im Log:

15.10.2013, 14:59:07: FETCH - Verbinde mit POP3-Server pop.gmx.de auf Port 110
15.10.2013, 14:59:07: FETCH - Einleitung TLS-Handshake
>15.10.2013, 14:59:07: FETCH - Zertifikat S/N: 429122A6486E892FBE9D106E7B3E8074, Algorithmus: RSA (2048 Bits), ausgestellt von 24.04.2013 bis 24.04.2015 23:59:59, für 1 Host(s): pop.gmx.net.
>15.10.2013, 14:59:07: FETCH - Besitzer: DE, Rhineland-Palatinate, Montabaur, 1&1 Mail & Media GmbH, pop.gmx.net.
>15.10.2013, 14:59:07: FETCH - Aussteller: US, Thawte, Inc., Thawte SSL CA.
>15.10.2013, 14:59:07: FETCH - Root: US, thawte, Inc., Certification Services Division, (c) 2006 thawte, Inc. - For authorized use only, thawte Primary Root CA
!15.10.2013, 14:59:07: FETCH - TLS-Handshakefehler. Keine Übereinstimmung zwischen Hostname ("pop.gmx.de") und Zertifikat.

PS: Überhaupt ist swaks nutzlos, weil ein brauchbarer Mail-Client ein eigenes, aussagekräftiges Log führt.
Nu mal langsam mit dem in die Tonne treten.

gio3:~ # dig mail.gmx.de
;; QUESTION SECTION:
;mail.gmx.de. IN A

;; ANSWER SECTION:
mail.gmx.de. 21045 IN CNAME mail.gmx.net.
mail.gmx.net. 345 IN A 212.227.17.190
mail.gmx.net. 345 IN A 212.227.17.168

gio3:~ # dig mail.gmx.fr
;; QUESTION SECTION:
;mail.gmx.fr. IN A

;; ANSWER SECTION:
mail.gmx.fr. 3600 IN CNAME mail.gmx.com.
mail.gmx.com. 600 IN A 74.208.5.30
mail.gmx.com. 600 IN A 74.208.5.1

gio3:~ # dig mail.gmx.co.uk
;; QUESTION SECTION:
;mail.gmx.co.uk. IN A

;; ANSWER SECTION:
mail.gmx.co.uk. 21600 IN CNAME mail.gmx.com.
mail.gmx.com. 600 IN A 74.208.5.30
mail.gmx.com. 600 IN A 74.208.5.1

Sowohl für mail.gmx.net als auch für mail.gmx.com liegen gültige Zertfikate vor.
Warum soll sich ein Mail-Client beschweren wenn er die "richtige" IPv4 Adresse ansteuert
und ein gültiges Zertifikat zurück bekommt.

Testet deine Fledermaus etwa gegen den NAMEN statt gegen die IPv4 Addresse?

-NoGi

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von SpaceRat » 15.10.2013, 19:43

NoGi hat geschrieben:
SpaceRat hat geschrieben:Übrigens bedeutet das, daß Du swaks auch gepflegt in die Tonne kloppen kannst.
Da sich das Teil völlig anders als ein brauchbarer Mail-Client verhält (Er weist ja nicht einmal auf das fehlerhafte Zertifikat hin), kann man damit eben auch keine Verbindungen zu einem Mail-Server austesten.

Das stünde bei einem guten Mail-Client (Hier: The Bat!) im Log:
!15.10.2013, 14:59:07: FETCH - TLS-Handshakefehler. Keine Übereinstimmung zwischen Hostname ("pop.gmx.de") und Zertifikat.

PS: Überhaupt ist swaks nutzlos, weil ein brauchbarer Mail-Client ein eigenes, aussagekräftiges Log führt.
Nu mal langsam mit dem in die Tonne treten.
Nö.
NoGi hat geschrieben:Sowohl für mail.gmx.net als auch für mail.gmx.com liegen gültige Zertfikate vor.
Korrekt.
Deshalb funktioniert der TLS-Handshake auch sowohl bei mail.gmx.net als auch bei mail.gmx.com (Sowie pop.gmx.net und pop.gmx.com).
*.gmx.com sind allerdings andere Server als die unter *.gmx.net verzeichneten, weswegen man schon die Server benutzen sollte, die GMX angibt, also bei "deutschen" Accounts gmx.net.
NoGi hat geschrieben:Warum soll sich ein Mail-Client beschweren wenn er die "richtige" IPv4 Adresse ansteuert und ein gültiges Zertifikat zurück bekommt.
Er kriegt eben kein gültiges Zertifikat präsentiert, sondern eines für einen prinzipiell betrachtet völlig anderen Server.
NoGi hat geschrieben:Testet deine Fledermaus etwa gegen den NAMEN statt gegen die IPv4 Addresse?
Verglichen wird grundsätzlich die aufgerufene Adresse mit der aus dem Zertifikat.
Die müssen zwingend übereinstimmen, sonst handelt es sich eben nicht um ein valides Zertifikat für die aufgerufene Adresse.

Anderes Beispiel:
Du willst Max Mustermann anrufen, der gerade aus dem Knast entlassen wurde, um ihm mitzuteilen, wo Du seinen Anteil der Beute aus dem gemeinsamen Banküberfall versteckt hast. Du findest noch eine alte Telefonnummer von ihm in Deinem Adressbuch und rufst an:
{Tipp tipp tipp}030-1234567{Tipp tipp tipp}
Der angerufene meldet sich: "Fritz Müller"

Würdest Du nun Fritz Müller mitteilen, wo Max Mustermanns Anteil der Beute ist, da ja Fritz Müller Max Mustermann sein muß, weil er dessen Telefonnummer hat?
Natürlich nicht ...

Oder wieder zum Online-Banking:
Da ich gerade die Website für meine neue Unternehmung "Swinger-Club Aachen" (swingerclub-aachen.de) aufgesetzt habe und dafür ein gültiges Zertifikat erworben habe, setze ich auch gleich noch eine Kopie der Website Deiner Hausbank auf und benutze dort mein Zertifikat vom Swinger-Club, denn ein Zertifikat für commerzbank.de wird mir kein vertrauenswürdiger Herausgeber erteilen, da mir die Seite nicht gehört.

Du rufst nun
https://banking.commerzbank.de
auf und Dank DNS-Spoofing landest Du auf meiner Kopie der Website Deiner Hausbank.
Diese Kopie präsentiert Dir auch ein Zertifikat, welches bescheinigt, daß Du "swingerclub-aachen.de" erreicht hast.

Würdest Du dann trotzdem Deine Kontonummer und PIN eingeben?
Natürlich nicht ...


Warum also sollte dann ein eMail-Client die Credentials für mail.gmx.de an einen Server schicken, der sich als mail.gmx.net ausweist?
Richtig, sollte er nicht, denn wie beim [zensiert] gibt es auch hier kein "ein bißchen schwanger". Entweder die Adresse stimmt mit der überein, die ich erreichen wollte, oder nicht. Es ist nicht an meiner Software zu entscheiden, daß der Fehler ja nur klein ist, es ist und bleibt ein Fehler. Wenn GMX gewollt hätte, daß mail.gmx.de und pop.gmx.de vollwertig genutzt werden können, hätten sie die Zertifikate entsprechend erweitern können!

Ein kleiner Gedankenanstoß: Die Domain gmx.cm ist frei. .cm ist die tld für Kamerun, unter dieser gibt es nur eine Handvoll legitimer Websites, aber Hunderte bis Tausende Phishing-Pendants zu Seiten mit der tld .com!
Da hast Du nur einen einzigen Buchstaben Abweichung und trotzdem wäre gmx.cm noch lange nicht derselbe Server wie gmx.com.

Und jetzt verrate ich Dir noch was:
Auf Online-Banking-Daten und PayPal-Logins geben die Leute noch einigermaßen Acht, immerhin sieht man ja den direkten Zusammenhang zwischen Einwahl und Risiko des Geldverlustes. eMail-Passwörter werden aber nicht annähernd so ernst genommen, man muß es sich ja auch leicht merken können, damit man sich in jedem versch... offenen WLAN in den WebMail-Zugang einloggen kann ... also "Schnucki84".

Deshalb sind inzwischen die eMail-Daten viel interessanter für Betrüger. Hat man die Kontrolle über das Larifari-eMail-Postfach, dann fällt der Rest nach dem Dominoprinzip: "Ich habe mein Passwort vergessen"-Links gibt es fast überall und in der Regel wird dann ganz einfach ein neues zugemailt.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Bernie72
erfahrener Kabelkunde
Beiträge: 99
Registriert: 20.12.2009, 18:08

Re: IP-Adressen von Unitymedia auf eMail-Blockliste

Beitrag von Bernie72 » 20.10.2013, 11:24

UM hatte mich letzte Woche angerufen und mitgeteilt, das dies ein bekanntes Problem von UnitedInternet (!&1, Web.de, GMX) ist.
Tatsächlich klappt es nun seit ein paar Tagen bei mir wieder!

Problem ist wohl gelöst.

Gruß

Bernie
2play Comfort 120
(eigene) Fritz!Box 6490
Technisat DigiCorder ISIO C mit
- Alphacrypt-Classic mit Sky Welt/BuLi/Sport/HD
- UM HD-Modul mit HD Option (TV-Start)

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste