|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
TLS bei SMTP ist nur bei SMTP-AUTH sinnvoll. Wenn man will, dass niemand mitliest, gibt es PGP.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 20:01 MET (#28)
|
|
|
|
|
Sorry die Frage, aber wieso ist es nur bei SMTP-AUTH sinnvoll? Werden ohne dies die Mails nicht verschlüsselt übertragen? Merci
|
|
|
|
|
|
|
|
|
|
|
|
|
Damit das Passwort nicht im Klartext übers Netz geht.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ausser bei SMTP AUTH sehe ich den Sinn von TLS nicht wirklich.
Wieso es die grossen nicht machen, ist ganz klar. Crypto braucht jede Menge Rechenleistung.
Wenn ich eine Mail versenden will, deren Inhaltlich vertraulich ist, so verwende ich GPG.
TLS bietet, ausser bei SMTP AUTH, keinerlei technische Vorteile, nur Nachteile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ausser bei SMTP AUTH sehe ich den Sinn von TLS nicht wirklich.
Den gibt es: Verschleiern von Kommunikationsranddaten.
--
Anyone can make an omelet with eggs. The trick is to make one with none.
|
|
|
|
|
|
|
|
|
|
|
|
|
Man sollte nicht versuchen, Soziale Probleme mit Technischen Loesungen anzufassen. IMHO. YMMV.
|
|
|
|
|
|
|
|
|
|
|
|
|
Addendum zum Posting von vorhin:
Wieso es die grossen nicht machen, ist ganz klar. Crypto braucht jede Menge Rechenleistung.
Kannst Du mir dann erklaeren, wieso viele der Grossen Mails auf Viren scannen, was noch mehr Rechenleistung als Crypto benoetigen duerfte aber nutzlos ist?
--
Anyone can make an omelet with eggs. The trick is to make one with none.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virenscannen kann man Kunden besser verkaufen.
NSG
--
The only nice thing about spam is that it doesn't ring.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 14:09 MET (#6)
|
|
|
|
|
|
Durch TLS wird verhindert, dass ein Provider genau die Kommunikationsranddaten erhält, die er möglicherweise seit Einführung des BÜPF irgendwo abspeichert. Angeblich sind sogenannte "Black Boxes" erhältlich, (wohl vor allem kleinere) Dienstleister einfach in den Datenverkehr hängen und die diesen dann mitsniffen. Gut möglich, dass da einfach SMTP abgehört wird, egal, mit welchem Server du nun Verbindung aufnimmst. Oder vielleicht kommt ja auch irgendein Schlaumeier mal auf die Idee, dass man solche Sniffer irgendwo zwangseinbauen könne, um wenigstens zu erfahren, wer mit wem kommuniziert. Dagegen hilft nur die zusätzliche Verschlüsselung des ganzen Datenverkehrs, nicht nur des Inhalts, wie bei GPG.
Voraussetzung, dass dies funktioniert, ist natürlich, dass dein Mail über keinen abgehörten Mailserver läuft. Für den Inhalt gibt's ja dann auch GPG.
|
|
|
|
|
|
|
|
|
Von kruemelmonster am Thursday 11. September, 14:16 MET (#8)
(User #3 Info)
|
|
|
|
|
Schade finde ich bei TLS, dass es zwar Authentifikation kann, diese aber nicht genutzt wird.
Ich stelle mir da was vor, wie bei SSH. Beim ersten mal wird der Fingerprint gespeichert, und in bei zukünftigen Verbindungen verglichen. Wie man dann den interaktiven part lösen will, oder ob man einfach ne Nachricht an den admin generiert (so im stile von: Achtung, da hat sich was geändert, ev. sitzt da wer dazwischen) sollte dnan halt der Postmaster selbst einstellen könen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 16:02 MET (#19)
|
|
|
|
|
Schon mal SSH in einer grösseren chaotischen Umgebung gesehen? Jeder zweite Login zaubert so eine 'Host Key changed' Meldung auf den Schirm und den User kratzts kein bisschen...
Jetzt stell dir das im Internet vor.. ne.. echt nicht, wer soll all diesen Warnungen nachrennen? Loadbalancing kann dann u.U. auch mühsam sein (jaja, je nach Implementierung).
Nein, wenn dann, tut man bei ausgewählten Verbindungen Zertifikate austauschen, aber he, wo ist der Sinn der Sache? Solange das Mail in eingen Abschnitten immer noch unverschlüsselt übetragen werden kann (Schwächstes Glied der Kette nicht bekannt -> unkontrollierbar) bringt die ganze Aktion einen Scheissdreck. In einer Firmenumgebung vielleicht, die das zwangsläufig aktiviert hat, aber auch da, viele Frimen verschlüsseln nur zwischen den Geschäftstellen, aber da gleich den kompletten Traffic.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 15:56 MET (#17)
|
|
|
|
|
Die Abhörung findet direkt auf dem Mailserver statt. Da nützt Dir TLS auch nichts mehr.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 21:37 MET (#32)
|
|
|
|
|
Nicht, wenn ich keinen Mailserver benütze, der überwacht wird (d.h. nicht einen Mailserver eines Fernmeldedienstanbieters, der dazu verpflichtet ist). Wenn ich natürlich selbst über einen solchen versende oder der Empfänger einen solchen verwendet, habe ich natürlich verloren.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 14:17 MET (#9)
|
|
|
|
|
Es müssen einfach viele anfangen, dann setzt sichs eher auch durch. Und es verschleierz zumindest die Kommunikation, schadet also nicht.
Kloine Frage: Kann man das auch einem MS Exchange SMTP Dienst beibringen?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kloine Frage: Kann man das auch einem MS Exchange SMTP Dienst beibringen?
Ja.
--
Anyone can make an omelet with eggs. The trick is to make one with none.
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm, weisst Du grad wie?
Ich hab bei beiden: Exch 5.5 und 2k mal TSL eingeschaltet. Bisher kommunizieren die aber nicht darüber mit meinem TSL Aware Linux Server, welcher immer mal wieder mit anderen TSL Server verschlüsselt kommuniziert.
Oder müssen da zuerst die Zertifikate ausgetauscht werden?
Btw Man-in-the-Middle Attacke. Hier capture ich allen Traffic von LAN nach InterNet, Port 25 und leite den an unseren internen Mailserver weiter zweck Abfangen der Viren unsere ach noch so auf alles klickenden User.
Mein Linux Notebook macht nun TSL und merkt nicht, dass es eigentlich, wenn es eine Mail nach aussen sendet, blos mit unserem internen Mailserver quatscht. Das würde es erst, wenn es die Zertifikate prüfen würde. Wie kriege ich nun aber die Zertifikate sämtlicher TSL Server im Netz auf meine Kiste?
Gruss
-Benoit-
|
|
|
|
|
|
|
|
|
|
|
|
|
Du musst IIRC zwei Optionen auswaehlen. Die einte ist irgendwo versteckt bei Protokolle - SMTP und die andere ist beim SMTP-Connector versteckt (erstere ist eingehend, letztere ausgehend).
--
Anyone can make an omelet with eggs. The trick is to make one with none.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 14:26 MET (#11)
|
|
|
|
|
Ich habe noch was witziges mit TLS angestellt:
Ich möchte gerne mail auf meinem Heimserver emfangen, der mit T-DSL (dyn-ip) angebunden ist. Ein dyndns Eintrag ist vorhanden, aber den MX Eintrag auf einen dyndns Host zu legen ist Kaputt. Statdessen geht die mail jetzt an einen anderen Server, dieser Server relayed die Mail jetzt an den eigentlichen, dynamisch angebundenen Server, hierbei wird aber über TLS das Zertifikat der Gegenseite überprüft, so dass niemand der zufällig meine IP bekommen hat und der dyndns noch nicht upgedatet ist meine Mail bekommt und lesen kann und/oder mich für einen Spammer hällt, der ihn als Relay missbrauchen möchte. Übrigens setzte ich dafür auf beidens Hosts exim 3 ein, ob das mit anderen MUAs so ähnlich geht weiss ich nicht.
Gruß
Martin
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
Kannst du bitte dieses Vorgehen genauer Dokumentieren? Am besten in Form eines Howtos zum Nachbasteln.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
112 deliveries über TLS, 1687 ohne!
Als einer der "Schuldigen" welcher einen vermutlich 2-stelligen Anteil an den 1687 hat, meld ich mich mal, warum ich kein TLS habe, und nicht vor habe zu installieren.
Inzwischen ist es auch nicht so schwer
Schwerer als den Mailservereinfach ohne weiter laufen zu lassen. Also wird die grosse Mehrheit das nur machen, wenn sie nen triftigen Grund haben. Und der fehlt.
Interessant finde ich, dass man TLS offenbar auch als "nospam-kriterium" nutzen kann
Nur temporaer bis die Spammer Mailboxen auf TLS-only Servern angreifen wollen. Und vor diesem Zeitpunkt ist ein TLS-only Server ein schwerer Nachteil bezieglich Erreichbarkeit. Also wird sich das niemand antun.
Wahrscheinlich kümmern sich Admins, die sich für TLS interessieren, auch darum, dass ihre Server ned als relay missbraucht werden können.
Relays sind heute immer weniger wichtig. Heute wird direkt gespammt, gibt genug Provider die das zulassen. Direkt geht auch mit TLS, ausser du beschraenkst dich auf bekannte Server (noch unwahrscheinlicher als nur bekannte pgp/gpg signierte Mails annehmen).
D.h., jemand, der den Mailverkehr abhören will, hat mindestens einen Angriffspunkt weniger!
Es gibt nur eine sichere Methode zu sehen das Daten sicher ankommen: end-to-end. Deshalb hat das Internet ja auch TCP ueber IP, statt auf jedem Link irgendwelches Gebastel, wie es in vor dem Internet Zeitalter ueblich war.
Genauso ist es mit Krypto. Nur end-to-end, also Client->Client, ist sicher. Also pgp/gpg fuer Mail. Alles andere ist Spielzeug, suggeriert pseudo Sicherheit. Nur Link sichern und dann im Mail Spool offen. Siehe deine eigene Bemerkung: TLS ist also absolut KEIN Ersatz für PGP oder so, damit entwertest du dieses Argument.
Sicher, die Kommunikation zwischen Client und Mailserver läuft immer noch in einem grossen Teil der Fälle unverschlüsselt.
Und gerade die sollte verschluesselt seien, weil man da ansetzt, wenn man gezielt Person X ausspionieren komplett will. Sogar ich als Krypto Muffel mach das seit >4 Jahren (ueber ssh Tunnel), wenn auch nur um mein POP3 Passwort (= Login Passwort) nicht jeden Sniffer zu geben.
Aber z.B. kann mein Provider, selbst wenn er vom Staat dazu aufgefordert wird, nicht einfach so meinen Mailverkehr belauschen
Das ist Mailbox->dir, also brauchst du da verschluesselte Reader->Mailbox Verbindung. Verschluesselte Ansender->Mailbox hilft da genau nix. Ausser der gehen auf die Leitung deines Mailserver Betreibers los. Und auch da hilft pgp/gpg genauso.
Wenn bloss die pgp/gpg Fanatiker endlich die Wichtigkeit von Komfort erkennen wuerden, um mehr User zu bekommen (und so dem Spionen mehr Kopfzerbrechen zu machen, und den wichtigen Verkehr besser zu verstecken).
Insbesondere ssh-artiges "Absender Public Key beim ersten mal notieren, spaetere Mails ueberpruefen". Und falls man extern gesichert uebertragen will, (gegen MITM gleich bei der ersten Uebertragung) ebenfalls ssh-artige ASCII Pubkey files, die man mit dem Editor bearbeitet.
Und dafuer all das zu komplizerte Trust Zeugs abschaffen (oder soweit fakultativ machen, das ein nicht-User nicht mal von dessen Existenz wissen muss).
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
|
|
|
|
|
Von kruemelmonster am Thursday 11. September, 14:50 MET (#13)
(User #3 Info)
|
|
|
|
|
Es gibt nur eine sichere Methode zu sehen das Daten sicher ankommen: end-to-end. Deshalb hat das Internet ja auch TCP ueber IP, statt auf jedem Link irgendwelches Gebastel, wie es in vor dem Internet Zeitalter ueblich war.
Genauso ist es mit Krypto. Nur end-to-end, also Client->Client, ist sicher. Also pgp/gpg fuer Mail. Alles andere ist Spielzeug, suggeriert pseudo Sicherheit. Nur Link sichern und dann im Mail Spool offen. Siehe deine eigene Bemerkung: TLS ist also absolut KEIN Ersatz für PGP oder so, damit entwertest du dieses Argument.
Wenn etwas keine Ersatz ist, kann es einer ergänzung sein, denn genaus das, was PGP nich leistet (leisten kann) macht TLS. Auch die "Randdaten" der E-Mails auf dem Transport verschlüsseln! Also das SMTP-Envelope wird auch verschlüsselt! Das ist ja genau das, woran der Schweizer überwacher so interessiert sind. Sie verlangen von den Providern, dass dieses zeugs gespeichert wird. Naja, MEIN Provider speichert von mir auch keine Envelopes, wenn der andere Mailserver TLS kann, selbst wenn er ne box hat, die auf der Leitung mitsnifft.
Es ist n Zusatz und kein Ersatz. Ausserdem vergrössert es die verschlüsselte Datenmenge im Internet, was es für die professionellen Datensammler schweiriger macht, die für sie interessanten Daten rauszufischen!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Auch die "Randdaten" der E-Mails auf dem Transport verschlüsseln! Also das SMTP-Envelope wird auch verschlüsselt! Das ist ja genau das, woran der Schweizer überwacher so interessiert sind.
Also fordern die Ueberwacher einfach das dein Provider auf port 25 einen transparenten Proxy haben, der MITM macht.
Ohne AUTH wird das unerkannt bleiben. Und auth wird nicht kommen, so lange man nicht ein ssh-maessigiges "trau dem ersten mal, teste danach obs der selbige ist" hat.
Und das wird nicht zum Standard werden, da machen die Paranoia Freaks nicht mit, trotz dem das ein MITM einen Anfang haben muss bevor der Server auch nur einem spaeter wieder kommenden externen Server bekannt ist. Und dann ewig fehlerfrei laufen muss, damit er nicht aufgedeckt wird.
Sie verlangen von den Providern, dass dieses zeugs gespeichert wird.
IIRC waren das die Daten vom Provider seinem eigenen Mailserver. Nicht die von Verbindungen die zu Port 25 eines Kunden gehen.
selbst wenn er ne box hat, die auf der Leitung mitsnifft
OK, so ne annonyme sniffer Box kann ja alles loggen, egal ob dem Gesetz entsprechend oder nicht. Rechenschaft gibt es da null. Und die Spionage Typen dazu bringen einen Vertrag, das saemtliche Gesetze eingehalten werden, mit ihrem eigenen Blut zu unterschreiben wird wohl kaum moeglich sein.
Ausserdem vergrössert es die verschlüsselte Datenmenge im Internet
Das hat was. Auch wenn die dann MITM machen koennen um das zu umgehen, ist es doch Mehraufwand. Und sei as auch nur zu wissen, was MITM-bar ist und was Alarm ausloest.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was für ein sinnloser Artikel!
Wenigstens einen Link zu einer Anleitung hätte ich erwartet. Stattdessen les ich nur Rumgenöhle. Die Installation von Sendmail mittels apt-get (wenn man denn überhaupt Debian benutzt, was ich nicht tue) reicht da noch lange nicht aus. Im sendmail.mc resp. dann sendmail.cd und submit.cf sollten die entsprechenden Optionen eingeschaltet sein, ebenso wie auch die Zertifikate generiert werden müssen.
--
Den Symlink-Autoren bei der Arbeit zuhören? MP3 hier
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 11. September, 16:31 MET (#22)
|
|
|
|
|
was benutzt du denn?
ein informationssüchtiger ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich benutze FreeBSD und NetBSD. Auf der Workstation hier hab ich zudem noch Slackware, weil ich zu faul zum die Umrüsten bin.
--
Den Symlink-Autoren bei der Arbeit zuhören? MP3 hier
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Meiner bescheidenen Meinung geht die Mailtechnologie langsam in die ewigen Jagdgründe, wegen Spams. Gibt ja mitlerweile gute IM-Systeme.
Und ja, ich könnte ein Spamfilter aufsetzen, aber wer hat Zeit und das Geld? Ich auf jedenfall nicht.
http://www.iframe.ch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und ja, ich könnte ein Spamfilter aufsetzen, aber wer hat Zeit und das Geld? Ich auf jedenfall nicht.
apt-get install spamassassin
perl -MCPAN -eshell
install Mail::SpamAssassin
oder
Zeitaufwand: Maximal 10 Minuten.
Konfigurationsaufwand: Außer cut&waste-Eintrag in der .procmailrc oder der .mailfilter praktisch keinen.
Reduktion des Spams um mind. 80% und nur sehr wenige "false positives" mit Standardinstallation.
Keine "false positives" mehr und deutlich höherer Trefferrate mit nach einiger Zeit angewandtem sa-learn.
Nenn mir bitte jetzt noch einen Grund gegen die Installation eines Spam-Filters. Windows? Oh! Ja, das ist ein Grund... Aber wer benutzt schon Windows? ;-)
--
There is no place like $HOME.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ne nicht windows, Linux mit Lotus Domino. Da das die Mails aber über die FW weitergeleitet werden könnte man dort die mails mit sendmail filtern.
.oO(Da hats anscheinend immer noch leute, die meinen symlinkleser nutzen windowsserver *kopfschüttel*)
http://www.iframe.ch
|
|
|
|
|
|
|
|
|
|
|
|
|
".oO(Da hats anscheinend immer noch leute, die meinen symlinkleser nutzen windowsserver *kopfschüttel*)"
Windows ist leistungsfähig genug, um ein oder zwei Personen zuverlässig und stabil zu versorgen (mal vorausgesetzt, man nimmt ein NT, befolgt ein paar Grundregeln und hat es mindestens hinter NAT stehen). Wieso sollte ich meine NT4-Box plätten, um hinterher mit Linux genau das gleiche zu machen, was sie jetzt schon seit 5 Jahren zuverlässig tut? So "religiös" bin ich nun mal nicht...
Grüsse vom Knochen
|
|
|
|
|
|
|
|
|
|
|
|
|
IM issn bisserle teuer, wenn man keine Flatrate hat, mein Lieber. Tja, und leider gibt es in ganz vielen Gegenden der Welt, wie z.B. Neufünfland keine flächendenkenden Flatrates... Naja, vielleicht setzt sich ja dieses SMTP-mit-Absenderzertifikat durch: Dann hat man nämlich wenigstens jemanden, denn man Anzeigen kann, wenn Spam kommt. (Ob der die auch versandt hat, steht auf 'nem ganz anderen Blatt - aber: wer die Schlüssel zum Waffenschrank offen rumliegen lässt, ist ja auch nicht unschuldig, wenn dann 'n Mord passiert....)
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
Macht es sinn TLS zu fahren ohne ein beglaubigtes Zertifikat vorweisen zu können? Ich meine da könnt dann ja jeder kommen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was ist ein beglaubigtes Zertifikat?
Solche von Verisign oder aehnlich sind ja ziemlich wertlos.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ausser das jeder Browser drauf vertraut?
Blöp
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich habe mal mit Leuten vom CCC über meine Idee
gesprochen und sie danach verwirklicht.
Wer auch immer MirBSD #7 installiert und danach
sendmail von localhost-only nach internet umbiegt
(den -C localhost.cf raus), verschickt schon
automatisch über TLS und nimmt auch über TLS an.
Präsentiert wird ein SnakeOil-Zertifikat, aber
in man 8 starttls findet man Hilfestellungen, wie
man Eigene generiert.
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Verschlüsselung zwischen den Servern macht absolut keinen Sinn! Die Technologie gibt dem Enduser nicht die Sicherheit, dass die E-Mail welche er schreibt bis zum enduser auch ungelesen und völlig verschlüsselt ankommt.
Ich unterstütze da mehr die Enduser Verschlüsselung ala PGP.
Cheers
Micressor
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 12. September, 12:31 MET (#42)
|
|
|
|
|
UCE wird in der Zukunft sicher nicht weniger, da sind wie uns sicher einig - und ob SPF (google nach SMTP und SPF) jemals kommen wird steht in den Sternen - wenn wir also in 10 Jahren weiterhin eMail haben wollen, werden wir ein Netzwerk haben müssen, wo wir sagen können: "dieser Host ist im Netz bekannt und darf senden" - TLS mit einem _offiziellen_ Zertifikat ist eine Variante - jeder der UCE verschickt bekommt das Cert revoked und muss ein neues erstellen...
Warum _ich_ das heute einsetze: GPG verschlüsselt zwar den Body, aber den Header und das ganze rumherum geht auch kein Schwein was an - ich bin halt so einer, der davon ausgeht, dass mein Traffic mein "Intellectual Property" ist und nicht zum mithören, kopieren und auswerten gedacht ist - insofern werde ich wohl der erste in der Schweiz sein, der "Opportunistic Encryption" im DNS eingebaut hat.
Warum es "big players" nicht verwenden? ganz einfach: es bringt 0 Gewinn... genausowenig wie es Gewinn bringt UCE zu filtern oder Viren zu filtern - Economy sucks!... darum verwenden wir auch Debian und nicht RedHat... und wenn hier einer klönt, dass er kein apt hat, ist er selber Schuld (ok ok... emerge und sonstige ports-derivate sind hier mal ausgeschlossen)
Wird wohl Zeit, dass nebst Key-Signing-Parties nun auch CA-Cert Parties gibt :)
|
|
|
|
|
|
|
|
|
|
|
|
|
Aber wie bringe ich andere Leute nun dazu, mein
Zertifikat zu akzeptieren?
Im Moment ist es über den Webserver (IPv6; IPv4
nur auf Port 180 wegen des Wurmtraffics) zu
beziehen (self-signed; eigene CA habe ich aufge-
geben, weil ich keine feste Domain habe und die
Leute, die mir die Subdomain delegieren, das gerne
nach nem halben Jahr "vergessen").
Hier könnte ja trash.net einspringen - Signieren
von SMTP Zertifikaten durch eine CA, die nur dazu
dient.
Oder eine Art "timestamping CA", die nur signiert
und danach an die eMail im CN sendet, aber die
anderen Angaben (außer critical,CA:FALSE) nicht
überprüft.
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
