Wie lautet das Home-Verzeichnis vom User (C++)
Olaf Radicke
Wie kann ich rausbekommen wie das Home-Verzeichnis vom
User heißt?
Weil ~/ kann ich offenbar mit .open() benutzen.
MfG Olaf
Patrick Schaaf
>Wie kann ich rausbekommen wie das Home-Verzeichnis vom
>User heißt?
man getenv
char *homedir = getenv("HOME");
>Weil ~/ kann ich offenbar mit .open() benutzen.
Eh? Was ist .open()? Hat das was mit diesem C++ zu tun?
Egal, "~/" geht nicht automatisch, das darf jedes Programm
fuer sich selbst programmieren. Wenn ich es richtig sehe,
dann nimmt man heutzutage eventuell
man 3 glob
dafuer (Option GLOB_TILDE).
Gruss
Patrick
Olaf Radicke
> Olaf Radicke <olaf...@gmx.de> writes:
>
>>Wie kann ich rausbekommen wie das Home-Verzeichnis vom
>>User heißt?
>
> man getenv
>
> char *homedir = getenv("HOME");
>
>>Weil ~/ kann ich offenbar mit .open() benutzen.
>
> Eh? Was ist .open()? Hat das was mit diesem C++ zu tun?
std::fstream datei;
datei.open("~/haste_nicht_jesehen.xml");
> Egal, "~/" geht nicht automatisch, das darf jedes Programm
> fuer sich selbst programmieren. Wenn ich es richtig sehe,
> dann nimmt man heutzutage eventuell
>
> man 3 glob
>
> dafuer (Option GLOB_TILDE).
Danke für die schnelle Antwort!
Olaf
Andreas Wiese
> Hi!
>
Hallo.
> Wie kann ich rausbekommen wie das Home-Verzeichnis vom
> User heißt?
>
Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
nicht wirklich empfehlenswert.
> Weil ~/ kann ich offenbar mit .open() benutzen.
>
Da fehlt ein 'nicht'. ~ ist ein Feature der verwendeten Shell und wird
von dieser expandiert.
> MfG Olaf
Gruesse,
awiese
--
Terrorismus ist der Krieg der Armen --
Krieg ist der Terrorismus der Reichen.
-- Sir Peter Ustionv, 03. Maerz 2003
Olaf Radicke
> Olaf Radicke <olaf...@gmx.de> dicebat:
>> Hi!
>>
>
> Hallo.
>
>> Wie kann ich rausbekommen wie das Home-Verzeichnis vom
>> User heißt?
>>
>
> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
> nicht wirklich empfehlenswert.
Wie so kann ich das in meinen "tollen" Büchern sowas nicht
finden *Grrr* - langsam nervt das. Wenn ich das alles für
0,87 Cent die Min. auf ein 56K-Modem online zusammen suchen
muss bin ich balt pleite.
Wie heißt die Header-Datei bitte?
>> Weil ~/ kann ich offenbar mit .open() benutzen.
>>
>
> Da fehlt ein 'nicht'.
...ja, völlig richtig!
MfG Olaf
Andreas Wiese
>> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
>> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
>> nicht wirklich empfehlenswert.
>
> Wie so kann ich das in meinen "tollen" Büchern sowas nicht
> finden *Grrr* - langsam nervt das. Wenn ich das alles für
> 0,87 Cent die Min. auf ein 56K-Modem online zusammen suchen
> muss bin ich balt pleite.
>
Linux-UNIX-Systemprogrammierung, H. Herold, Addison-Wesley, ISBN
3-8273-1512-3, EUR 49,95.
> Wie heißt die Header-Datei bitte?
>
Das sollte in den Manpages stehen: <unistd.h> fuer getuid() und
getlogin() und <pwd.h> fuer getpw*().
[snip...]
Gruesse,
awiese
--
> Ich verstehe nicht wieso die Leute immer ISO's haben wollen...
^
-----------------------. Was fuer ein Stilbruch,
Robert Lange in dcoulm | da gehoert ein Akzent hin.
Christoph Bartoschek
...
>> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
>> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
>> nicht wirklich empfehlenswert.
...
> Wie heißt die Header-Datei bitte?
Die (3) hinter dem Funktionsnamen nennt dir die Sektion der Manpages in der
der Befehl erklärt wird. Also "man 3 getpwnam" wird schon alles sagen.
Und das extern "C" nicht vergessen. :)
Christoph
Olaf Radicke
> Olaf Radicke wrote:
>
> ...
>>> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
>>> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
>>> nicht wirklich empfehlenswert.
> ...
>> Wie heißt die Header-Datei bitte?
>
> Die (3) hinter dem Funktionsnamen nennt dir die Sektion der Manpages in
> der der Befehl erklärt wird. Also "man 3 getpwnam" wird schon alles sagen.
[or@localhost or]$ man 3 getpwnam
Keine Handbuch-Seite getpwnam in der Sektion 3
Es muss noch einen signifikanten Unterschied geben,
zwischen dem was du meinst und dem was ich verstanden habe...
MfG Olaf
Andreas Wiese
> Christoph Bartoschek wrote:
>> Olaf Radicke wrote:
>> ...
>>
>> Die (3) hinter dem Funktionsnamen nennt dir die Sektion der Manpages in
>> der der Befehl erklärt wird. Also "man 3 getpwnam" wird schon alles sagen.
>
> [or@localhost or]$ man 3 getpwnam
> Keine Handbuch-Seite getpwnam in der Sektion 3
>
> Es muss noch einen signifikanten Unterschied geben,
> zwischen dem was du meinst und dem was ich verstanden habe...
>
Du wirst wahrscheinlich die entsprechenden Manpages nicht installiert
haben.
[snip...]
Gruesse,
awiese
--
What do I have but negativity / 'Cause I can't justify the way everyone is
looking at me / Nothing to lose / Nothing to gain / Hollow and alone / And
the fault is my own / And the fault is my own.
-- Linkin Park / "Somewhere I belong"
Olaf Radicke
> Olaf Radicke <olaf...@gmx.de> dicebat:
>> Andreas Wiese wrote:
>>> Olaf Radicke <olaf...@gmx.de> dicebat:
> [snip... Wie heisst Homeverzeichnis eines Users?]
>>> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
>>> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
>>> nicht wirklich empfehlenswert.
>>
>> Wie so kann ich das in meinen "tollen" Büchern sowas nicht
>> finden *Grrr* - langsam nervt das. Wenn ich das alles für
>> 0,87 Cent die Min. auf ein 56K-Modem online zusammen suchen
>> muss bin ich balt pleite.
>>
>
> Linux-UNIX-Systemprogrammierung, H. Herold, Addison-Wesley, ISBN
> 3-8273-1512-3, EUR 49,95.
>
>> Wie heißt die Header-Datei bitte?
>>
>
Mal ein Blindversuch mit
#include <cunistdh>:
> Das sollte in den Manpages stehen: <unistd.h> fuer getuid() und
cunistdh: No such file or directory
> getlogin() und <pwd.h> fuer getpw*().
Und noch einer...
cpwdh: No such file or directory
Schade :-(
Olaf
Olaf Radicke
> Olaf Radicke <olaf...@gmx.de> dicebat:
>> Christoph Bartoschek wrote:
>>> Olaf Radicke wrote:
>>> ...
>>>> Wie heißt die Header-Datei bitte?
>>>
>>> Die (3) hinter dem Funktionsnamen nennt dir die Sektion der Manpages in
>>> der der Befehl erklärt wird. Also "man 3 getpwnam" wird schon alles
>>> sagen.
>>
>> [or@localhost or]$ man 3 getpwnam
>> Keine Handbuch-Seite getpwnam in der Sektion 3
>>
>> Es muss noch einen signifikanten Unterschied geben,
>> zwischen dem was du meinst und dem was ich verstanden habe...
>>
>
> Du wirst wahrscheinlich die entsprechenden Manpages nicht installiert
> haben.
>
ja, das stimmte. *lauf rot an*
Olaf
denis
> #include <cunistdh>:
>
>> Das sollte in den Manpages stehen: <unistd.h> fuer getuid() und
>
> cunistdh: No such file or directory
unistd.h ist kein Standard-Header und liegt somit auch nicht im
namespace std.
Rainer Weikusat
> Olaf Radicke <olaf...@gmx.de> (2003-05-24, 18:20) wrote:
>> #include <cunistdh>:
>>
>>> Das sollte in den Manpages stehen: <unistd.h> fuer getuid() und
>>
>> cunistdh: No such file or directory
>
> unistd.h ist kein Standard-Header
Aber ganz sicher doch. Wir haben hier ein unix im Gruppenamen, kein
C++.
Juergen Ilse
>> Keine Handbuch-Seite getpwnam in der Sektion 3
Versuch es mal mit "LANG=C man 3 getpwnam". Die deutschsprachigen
man-Pages sind nicht immer vollstaendig ...
> Du wirst wahrscheinlich die entsprechenden Manpages nicht installiert
> haben.
Die Moeglichkeite besteht natuerlich auch noch ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
[ Alfred Schulze ueber Norton Internet Security in dcsf ]
Es ist ja eigentlich auch nicht zum runterbekommen gemacht.
Normalerweise gehoert es genau wie ein Windows ein Leben
lang auf den Computer.
denis
> denis <mu_...@yahoo.de> writes:
>> unistd.h ist kein Standard-Header
>
> Aber ganz sicher doch. Wir haben hier ein unix im Gruppenamen, kein
> C++.
Sorry, ich meinte natürlich Standard-C++-Header. Ging ja darum, dass
jemand versucht hat <cunistd> einzubinden. Den gibt es halt nicht.
Olaf Radicke
O.K.
Ich habe es jetzt hinbekommen. Was mir nicht klar war,
war das die C-Header-Dateien ganz normal inkludiert werden
können. Aus einem Missverstäntniss herraus dachte ich,
alle C-Header hissen bei C++ <c****h>.
Olaf
Stefan Reuther
Andreas Wiese <awiese....@t-online.de> wrote:
> Olaf Radicke <olaf...@gmx.de> dicebat:
>> Wie kann ich rausbekommen wie das Home-Verzeichnis vom
>> User heißt?
> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
> nicht wirklich empfehlenswert.
DOCH!
Die Shell expandiert "~" zu "$HOME", also sollte auch dein
Programm das so tun. "getpwXXX" brauchst du nur für "~userid".
Wenn ein Programm $HOME auswertet, kann man es "mal eben" in ein
temporäres Verzeichnis umleiten. Wenn das Programm darauf
besteht, "getpwXXX" zu verwenden, geht das nicht mehr.
Stefan
Juergen Ilse
Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
> Andreas Wiese <awiese....@t-online.de> wrote:
>> Olaf Radicke <olaf...@gmx.de> dicebat:
>>> Wie kann ich rausbekommen wie das Home-Verzeichnis vom
>>> User heißt?
>> Mit getpwnam(3) bzw. getpwuid(3) in Verbindung mit z.B. getlogin(2)
>> bzw. getuid(2). Alternativ auch per getenv("HOME"), aber das ist
>> nicht wirklich empfehlenswert.
In den meisten Faellen ACK.
> DOCH!
> Die Shell expandiert "~" zu "$HOME", also sollte auch dein
> Programm das so tun. "getpwXXX" brauchst du nur für "~userid".
Ist bekannt, und gerade das wird der Grund fuer den Hinweis gewesen sein.
> Wenn ein Programm $HOME auswertet, kann man es "mal eben" in ein
> temporäres Verzeichnis umleiten. Wenn das Programm darauf
> besteht, "getpwXXX" zu verwenden, geht das nicht mehr.
Eben, und deshalb moechte man das zumindest bei Anwendungen, die in
irgendeiner Weise sicherheitsrelevant sind, auf keinen Fall tun und
moeglichst auch diese Moeglichkeit aus dem Programm entdernen.
Patrick Schaaf
>> Wenn ein Programm $HOME auswertet, kann man es "mal eben" in ein
>> temporäres Verzeichnis umleiten. Wenn das Programm darauf
>> besteht, "getpwXXX" zu verwenden, geht das nicht mehr.
>Eben, und deshalb moechte man das zumindest bei Anwendungen, die in
>irgendeiner Weise sicherheitsrelevant sind, auf keinen Fall tun und
>moeglichst auch diese Moeglichkeit aus dem Programm entdernen.
Kannst Du dazu bitte mal ein konkretes Beispiel geben?
Welche sicherheitsrelevanten Anwendungen verlassen sich auf etwas,
das unsicher wird, wenn nicht der Hardcode-Wert aus /etc/passwd
als Homeverzeichnis genommen wird?
Fuer nicht-setuid-X Executables waere das sowieso broken, weil ich
einfach mit LD_PRELOAD open() und read() ueberschreiben kann,
wenn mir danach ist.
Fuer setuid-X Executables sollte das hoffentlich nicht machbar sein;
da moechte ich in Frage stellen, was sie ueberhaupt sinnvoll aus
Home-Verzeichnissen lesen moechten, und wie das dann genau Unsicherheit
erzeugen sollte.
Habe ich da einen Denkfehler? Hast Du ein Beispiel?
Gruss
Patrick
Stefan Reuther
>>> Wenn ein Programm $HOME auswertet, kann man es "mal eben" in ein
>>> temporäres Verzeichnis umleiten. Wenn das Programm darauf
>>> besteht, "getpwXXX" zu verwenden, geht das nicht mehr.
>>Eben, und deshalb moechte man das zumindest bei Anwendungen, die in
>>irgendeiner Weise sicherheitsrelevant sind, auf keinen Fall tun und
>>moeglichst auch diese Moeglichkeit aus dem Programm entdernen.
> Kannst Du dazu bitte mal ein konkretes Beispiel geben?
Würde mich auch interessieren.
> Welche sicherheitsrelevanten Anwendungen verlassen sich auf etwas,
> das unsicher wird, wenn nicht der Hardcode-Wert aus /etc/passwd
> als Homeverzeichnis genommen wird?
Meiner Meinung nach muß ein Programm "Tilde-Expansion" nur in
zwei Fällen kennen:
- um Konfigurationsdateien zu finden. Die stehen sowieso unter
der Kontrolle des Nutzers. Wenn der Nutzer zwei Sätze
Konfigurationsdateien haben will, soll er sie auch bekommen
können. Ich starte hier z.B. gelegentlich für einen Webseiten-
Test $URALTVERSION von Netscape, und leite den halt nach /tmp
um, damit er mir mein "echtes" Profil nicht versaut. Und
selbst wenn ich mir damit in den Fuß schießen würde, möchte
ich nicht, daß mir das Programm diese Möglichkeit verbaut, weil es
meint, schlauer zu sein als ich. Wir sind hier in .unix, nicht
in .windows.
- um in Dateinamen, die das Programm selbst einliest, Tilde-
Expansion anbieten zu können. Was für einen Sinn hat es da,
absolute Sicherheit bei der Tilde-Expansion zu fordern, wenn
ich eh jeden möglichen Pfad angeben kann?
> Fuer setuid-X Executables sollte das hoffentlich nicht machbar sein;
> da moechte ich in Frage stellen, was sie ueberhaupt sinnvoll aus
> Home-Verzeichnissen lesen moechten, und wie das dann genau Unsicherheit
> erzeugen sollte.
Mir fällt bestenfalls ein höchst obskurer Fall ein: ein
Backup-Programm (setuid root, damit es auf das Bandlaufwerk
zugreifen kann) erlaubt Nutzern, selbstständig den Restore von
bestimmten Dateien anzustoßen. Da muß natürlich sichergestellt
werden, daß jeder nur "seine" Dateien wiederherstellen kann.
Eine Möglichkeit, das zu lösen, wäre, jedem Nutzer nur den
Restore von Dateien innerhalb seines Homeverzeichnis' zu
erlauben. Damit könnten Nutzer z.B. setuid-Executables aus ihrem
$HOME/bin wiederherstellen. Ob das ein Vor- oder Nachteil ist,
bliebe zu debattieren. Die andere Möglichkeit wäre,
Eigentümerschaft zu testen, und sicherzustellen, daß der Nutzer
Eigentümerschaft oder Schreibrecht auf das enthaltende
Verzeichnis hat.
Aber das ist bestenfalls die Ausnahme, nicht die Regel.
Stefan
Bodo Thiesen
> Andreas Wiese <awiese....@t-online.de> wrote:
>> Olaf Radicke <olaf...@gmx.de> dicebat:
>>> [or@localhost or]$ man 3 getpwnam
>>> Keine Handbuch-Seite getpwnam in der Sektion 3
>
> Versuch es mal mit "LANG=C man 3 getpwnam". Die deutschsprachigen
> man-Pages sind nicht immer vollstaendig ...
1. Wäre dafür LANG=EN statt LANG=C besser gewesen, und
2. Holt sich mein man automatisch die englische Version, wenn es keine
deutsche gibt (LANG=de_DE)
>> Du wirst wahrscheinlich die entsprechenden Manpages nicht installiert
>> haben.
>
> Die Moeglichkeite besteht natuerlich auch noch ...
Ja, das wird's wohl sein...
--
Gruß, Bodo [DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Wer fragt ist nur drei Minuten Dumm.
Bodo Thiesen
> Ich habe es jetzt hinbekommen. Was mir nicht klar war,
> war das die C-Header-Dateien ganz normal inkludiert werden
> können. Aus einem Missverstäntniss herraus dachte ich,
> alle C-Header hissen bei C++ <c****h>.
Bei C: *.h
Bei C++: Die in C enthaltenen Headerdateien: *.h
Alle rein C++-Headerdateien: * (ohne .h)
Glaub ich zumindest...
Bodo Thiesen
> Olaf Radicke <olaf...@gmx.de> dicebat:
>>
>> Wie so kann ich das in meinen "tollen" Büchern sowas nicht
>> finden *Grrr* - langsam nervt das. Wenn ich das alles für
>> 0,87 Cent die Min. auf ein 56K-Modem online zusammen suchen
>> muss bin ich balt pleite.
>
> Linux-UNIX-Systemprogrammierung, H. Herold, Addison-Wesley, ISBN
> 3-8273-1512-3, EUR 49,95.
Für das Geld (Strom u.ä. nicht mitgerechnet) kann er sich 2GB runterladen.
Also ist das Buch zu teuer. [SCNR]
Juergen Ilse
Bodo Thiesen <bot...@gmx.de> wrote:
> Juergen Ilse schrieb:
>> Andreas Wiese <awiese....@t-online.de> wrote:
>>> Olaf Radicke <olaf...@gmx.de> dicebat:
>>>> [or@localhost or]$ man 3 getpwnam
>>>> Keine Handbuch-Seite getpwnam in der Sektion 3
>> Versuch es mal mit "LANG=C man 3 getpwnam". Die deutschsprachigen
>> man-Pages sind nicht immer vollstaendig ...
> 1. Wäre dafür LANG=EN statt LANG=C besser gewesen, und
Warum? LANG=C funktioniert (wenn nicht, ist vermutlich irgendetwas an
deinem System faul).
> 2. Holt sich mein man automatisch die englische Version, wenn es keine
> deutsche gibt (LANG=de_DE)
Das sollte zwar so sein, muss aber nicht immer. Es duerfte auf den Einzel-
fall ankommen ...
René Möhring
Bodo Thiesen <bot...@gmx.de> wrote:
> Olaf Radicke schrieb:
>
> > Ich habe es jetzt hinbekommen. Was mir nicht klar war,
> > war das die C-Header-Dateien ganz normal inkludiert werden
> > können. Aus einem Missverstäntniss herraus dachte ich,
> > alle C-Header hissen bei C++ <c****h>.
>
> Bei C: *.h
> Bei C++: Die in C enthaltenen Headerdateien: *.h
> Alle rein C++-Headerdateien: * (ohne .h)
>
> Glaub ich zumindest...
Korrektur:
C++: Die Standardheader sind ohne .h (z.B.: #include <iostream>)
Sollen die C-Standardfunktionen mitbenutzt werden, wird ebenfalls ohne
.h aber mit vorangestelltem c genommen (z.B.: #include <cstdio>). Dann
sind die Standard-C-Funktionen auch im Namensraum std.
Bodo Thiesen
> Hallo,
>
> Bodo Thiesen <bot...@gmx.de> wrote:
>> Juergen Ilse schrieb:
>>> Andreas Wiese <awiese....@t-online.de> wrote:
>>>> Olaf Radicke <olaf...@gmx.de> dicebat:
>>>>> [or@localhost or]$ man 3 getpwnam
>>>>> Keine Handbuch-Seite getpwnam in der Sektion 3
>>> Versuch es mal mit "LANG=C man 3 getpwnam". Die deutschsprachigen
>>> man-Pages sind nicht immer vollstaendig ...
>> 1. Wäre dafür LANG=EN statt LANG=C besser gewesen, und
>
> Warum?
Weil in LANG die Sprache des Benutzers definiert wird.
>LANG=C funktioniert
... weil Dein System / Deine Programme kaputt sind
>(wenn nicht, ist vermutlich irgendetwas an deinem System faul).
Ich denke nicht.
~~~
Nenne mir bitte den RFC oder die ISO-Norm, wo C als internationaler
Ländercode definiert ist.
>> 2. Holt sich mein man automatisch die englische Version, wenn es keine
>> deutsche gibt (LANG=de_DE)
>
> Das sollte zwar so sein, muss aber nicht immer.
... wenn etwas kaputt ist. Genau meine Rede.
> Es duerfte auf den Einzelfall ankommen ...
Fehler sind meistens Einzelfälle, ja.
Nis Martensen
>
> ... weil Dein System / Deine Programme kaputt sind
Unsinn. "C" entspricht der "POSIX"-locale.
> Nenne mir bitte den RFC oder die ISO-Norm, wo C als internationaler
> Laendercode definiert ist.
http://www.unix-systems.org/single_unix_specification/
Nis
Rainer Weikusat
>>> 1. Wäre dafür LANG=EN statt LANG=C besser gewesen, und
>>
>> Warum?
>
> Weil in LANG die Sprache des Benutzers definiert wird.
Nein.
LANG
This variable shall determine the locale category for native
language, local customs, and coded character set in the
absence of the LC_ALL and other LC_* ( LC_COLLATE , LC_CTYPE ,
LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) environment
variables. This can be used by applications to determine the
language to use for error messages and instructions, collating
sequences, date formats, and so on.
>>LANG=C funktioniert
>
> ... weil Dein System / Deine Programme kaputt sind
POSIX Locale
Conforming systems shall provide a POSIX locale, also known as
the C locale. The behavior of standard utilities and
functions in the POSIX locale shall be as if the locale was
defined via the localedef utility with input data from the POSIX
locale tables in Locale Definition .
The tables in Locale Definition describe the characteristics and
behavior of the POSIX locale for data consisting entirely of
characters from the portable character set and the control
character set. For other characters, the behavior is
unspecified. For C-language programs, the POSIX locale shall be
the default locale when the setlocale() function is not called.
The POSIX locale can be specified by assigning to the
appropriate environment variables the values "C" or "POSIX" .
[beides SUSv3]
Bodo Thiesen
>Weil in LANG die Sprache des Benutzers definiert wird.
Ich nehme alles zurrück und behaupte das Gegenteil.
Gruß, Bodo
--
MS Outlook Express?->[DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Probleme mit Spam? [EN: http://www.spamhaus.org/globalremove.html]