![[Comp.Sci.Dept, Utrecht]](/icons/li-dsol.png)
Note from archiver<at>cs.uu.nl:
This page is part of a big collection
of Usenet postings, archived here for your convenience.
For matters concerning the content of this page,
please contact its author(s); use the
source, if all else fails.
For matters concerning the archive as a whole, please refer to the
archive description
or contact the archiver.
Subject: <2004-05-06> FAQ, Abkuerzungen: de.admin.net-abuse.mail
This article was archived around: 18 Nov 2004 21:55:39 GMT
Archive-name: de-net-abuse/mail-faq
Posting-Frequency: 14 days
Last-modified: 2004-05-06
URL: http://www.irrlicht.net/~laura/de.admin.net-abuse.mail.txt
HTML-Versionen dieser FAQ können hier abgerufen werden:
* Internet FAQ Consortium:
http://www.faqs.org/faqs/de-net-abuse/mail-faq/
* Utrecht University:
http://www.cs.uu.nl/wais/html/na-dir/de-net-abuse/mail-faq.html
de.admin.net-abuse.mail E-Mail-Mißbrauch
========================================
Wichtiges Vorwort zur Gruppennutzung
====================================
"Diese Gruppe ist keine Kontaktbörse, um seinen Spam auszutauschen."
-- Andreas M. Kirchwitz in <slrnbkse5j.f0l.amk@krell.zikzak.de>
de.admin.net-abuse.mail ist keine Gruppe, in der erhaltener Spam einfach
unkommentiert abgekippt werden soll. Fast alle Leser der Gruppe erhalten
mehr als genug Spam, deswegen ist es sehr wichtig, daß nur solche Sachen
in der Gruppe veröffentlicht werden, bei denen der Poster eine Frage hat,
die er durch das Lesen der Gruppen-FAQs nicht klären konnte, oder die von
allgemeinem Interesse sind. Vor dem Posten sollte sich zudem vergewissert
werden, ob in der Gruppe nicht bereits ein Thread zum entsprechenden Thema
läuft.
Dies und das Beherzigen der unter "C. Hinweise zur Gruppennutzung" aufge-
führten Punkte soll sicherstellen, daß die Gruppe lesbar bleibt und insbe-
sondere die helfenden User nicht überstrapaziert werden.
Letzte Änderungen
=================
Ein diff der letzten geposteten Version gegen die neue Version
(wobei "faq" die alte Version und "de.admin.net-abuse.mail.txt"
die neue Version der FAQ ist) findet sich unter:
http://www.irrlicht.net/~laura/danam-diff
Inhalt
======
A. Charta
B. Abkürzungsverzeichnis und Begriffserklärung
C. Hinweise zur Gruppennutzung
D. FAQ - Frequently Asked Questions
D1. Übersicht über die Fragen
D2. Fragen mit Antworten
E. Andere Dokumente und Newsgruppen
A. Charta
=========
In de.admin.net-abuse.mail wird der Mißbrauch von E-Mail und
vorsätzliches Fehlverhalten beim Versand von E-Mail diskutiert.
Außerdem werden hier die in de.admin.net-abuse.announce
veröffentlichten Maßnahmen diskutiert, soweit sie E-Mail betreffen.
B. Abkürzungsverzeichnis und Begriffserklärung
==============================================
UCE ist die Abkürzung für "unsolicited commercial email", also
"unverlangte kommerzielle E-Mail". Damit meint man unerwünschte
Werbung per E-Mail, die man mit an Sicherheit grenzender Wahr-
scheinlichkeit bekommt, wenn man häufiger in den News schreibt
oder seine Adresse auf Webseiten veröffentlicht.
UBE Siehe UCE, mit B für Bulk ("Masse"). UBE bezeichnet unverlangte
und damit oftmals unerwünschte Massenmail.
MMF steht für "make money fast". Häufiges Subject von Kettenbriefen,
die für (verbotene) Schneeball- oder Pyramidensysteme nach dem
Schema "Schicke $1 an die fünf Leute am Ende der Liste, schreibe
Dich selbst auf die Liste und verteile diese Mail an so viele
Leute wie möglich" werben. Die Bezeichnungen "MMF" resp. "make
money fast" werden gerne als Synonyme für diese Art System be-
nutzt. Andere häufig anzutreffende Subjects solcher Kettenbriefe
sind z.B. "Easy Cash" oder "Turn 5$ into $50,000".
MLM ist die Abkürzung für "multi level marketing". Andere Begriffe
sind "Network Marketing" oder "Strukturvertrieb". Sie bezeichnen
Marketing-Systeme, in denen der Kunde selbst Teil der Vertriebs-
struktur werden kann und soll. Bekannte Beispiele für Multi Level
Marketing sind z.B. Herbalife und Amway. Für weitere Ausführungen
und Definitionen siehe
* Grundbegriffe des Multi Level Marketings
http://www.zingel.de/mlm_d.htm
* Informationen zur MLM-Schwemme Frühjahr / Sommer 2001
http://www.trash.net/~roman/mlm/ (Roman Racine)
MTA bedeutet Mail Transfer Agent. Eine Maschine, auf der ein MTA
seine Arbeit verrichtet, nennt man Mailserver. Ein MTA ist ein
Programm, das Mail annimmt und weiterleitet. Bekannte MTAs sind
z.B. Sendmail, Exim, Qmail oder Postfix.
MUA bedeutet Mail User Agent, also das, was man einen "Mailreader"
nennt. Bekannte MUAs sind pine, mutt, elm, Eudora, Pegasus,
Outlook Express, Netscape oder Agent.
MX steht für Mail Exchange. Ein MX ist ein Eintrag im DNS (Domain
Name Service), der angibt, welche Mailserver zuständig sind,
Mail für eine Domain oder einen Rechner anzunehmen.
SMTP bedeutet Simple Mail Transfer Protocol. Es ist also - wie der
Name schon sagt - ein Protokoll zum Mailtransport, sozusagen
die Sprache, in der Mailserver miteinander reden.
POP3 steht für Post Office Protocol - Version 3. POP3 ist ein
Protokoll zum Abrufen von Mail von einem Mailserver.
IMAP bedeutet Internet Message Access Protocol. Meistens liest
man von IMAP4, dem Internet Message Access Protocol in der
Version 4. IMAP4 ist ein Protokoll, mit dem man auf Mailboxen
auf einem Mailserver zugreifen kann und als besonderes Feature
sehr umfangreiche Möglichkeiten hat, mit der Mail auf dem
Mailserver zu verfahren, als läge sie auf der lokalen Maschine.
Das umschließt z.B. das Löschen von Mail oder Teilen von
Mail, das Löschen, Einrichten oder Umbenennen von Mailfoldern,
das Setzen von Flags und vieles mehr.
SPAM ist eine Art Büchsenfleisch, wie es besonders in den USA und
Grossbritannien sehr beliebt ist. Monty Python haben dieses
Lebensmittel sogar in einem Sketch thematisiert. Auf diesem
Sketch beruht auch die Übertragung des Wortes "Spam" auf Netz-
mißbrauch (ursprünglich nur auf mißbräuchliche Newsartikel;
mehr dazu weiter unten). Daß "Spam" für "Spiced Pork And Meat"
(oder auch "Spiced Pork And haM") steht, stammt ebenfalls aus
dem Umfeld des Sketches, laut Hersteller des Büchsenfleisches
ist dieses jedoch nicht authentisch:
Q: Who came up with the name SPAM?
A: Jay C. Hormel wanted a name as distinctive as the taste, so
he held a contest. Kenneth Daigneau, an actor and brother of
a Hormel vice president, pocketed the $100 prize.
(http://www.spam.com/sp/sp_fq.htm)
Wer mehr darüber erfahren möchte, was es mit dem Monty-Python-
Sketch auf sich hat und wie man von dem mittlerweile zum "Kult"
gewordenen Büchsenfleisch "SPAM" der Firma Hormel aus Minnesota
auf Netzmißbrauch kam:
* Hormel Food und SPAM
http://www.spam.com/ci/ci_hf.htm
* Das Internet und SPAM
http://www.spam.com/ci/ci_in.htm
* Dan Garcia's Spam Page
http://www.cs.berkeley.edu/~ddgarcia/spam.html
OPT-IN / OPT-OUT / DOUBLE OPT-IN
"opt-in" (engl. "to opt" = "sich entscheiden, wählen") bedeutet,
daß man eine (regelmäßige) Zusendung nur dann erhält, wenn man
sie explizit angefordert resp. ihr zugestimmt hat. Ein Beispiel
für "opt-in" wäre z.B. ein wöchentlicher Newsletter, für den man
sich auf einer Webseite angemeldet hat.
Im Gegensatz dazu bedeutet "opt-out", daß man eine (regelmäßige)
Zusendung unaufgefordert erhält und dem explizit widersprechen
muss, um sie nicht mehr zu erhalten.
"double opt-in" ist eine Variation des "opt-in", die Mißbrauch
erschweren soll (z.B. daß eine dritte Person fremde Mailadressen
über ein Webinterface für einen Newsletter anmelden kann), die
Anmeldung muss doppelt (daher "double") bestätigt werden. Die
häufigste Variante des "double opt-in" ist eine einfache Anmeld-
ung über ein Webinterface, die eine Mail an die eingetragene
Adresse generiert und den Inhaber dieser Adresse auffordert, die
Anmeldung nochmals zu bestätigen. Nur wenn die Anmeldung nochmals
bestätigt wird (z.B. durch das Aufrufen einer bestimmten URL oder
durch das Zurücksenden einer Bestätigungsmail), wird der Eintrag
in den Newsletter, die Mailingliste etc. vorgenommen.
Weitere Informationen zum Themenbereich "opt-in / opt-out":
* An Opt-In Manifesto
http://www.euro.cauce.org/en/manifesto.html
* Opt-In vs. Opt-Out
http://www.euro.cauce.org/en/optinvsoptout.html
NIGERIA CONNECTION / 419 CONNECTION
Hinter den Begriffen "Nigeria Connection" oder "419 Connection"
verbirgt sich eine Form des Vorauszahlungsbetrugs. Eine Mail ver-
spricht Provisionen in Millionenhöhe für eine kleine Gefälligkeit
(das Einrichten eines Kontos), mit deren Hilfe Kapital aus einem
afrikanischen Land geschafft werden soll. Ziel dieses nur schein-
bar verlockenden Angebotes ist es, finanzielle Vorausleistungen
zu erschleichen, die man natürlich niemals wiedersehen wird.
Ausführliche Informationen finden sich hier:
* Nigeria-Connection
http://www.internetfallen.de/Betrug_Abzocke/Kapitalanlage/Nigeria/nigeria.html
* Kapitalanlagebetrug
http://www.internetfallen.de/Betrug_Abzocke/Kapitalanlage/kapitalanlage.html
* Vorauszahlungsbetrug "Nigeria-Connection" ("419-Connection")
http://www.auswaertiges-amt.de/www/de/laenderinfos/419_html
* Der 419-Betrug als nigerianisches Phänomen?
http://www.v-d-boom.de/419.html
* Warnhinweis zu "Geschäftsvorschlägen" aus Afrika
http://www.berlin.de/polizei/LKA/lka3warnhinweis.html
* United States Secret Service
http://www.secretservice.gov/alert419.shtml
C. Hinweise zur Gruppennutzung
==============================
* Ein häufiges Thema ist unverlangte Massen- oder Werbe-Mail
(UBE/UCE). Verallgemeinernd und vereinfacht wird bei uner-
wünschter Mail auch von "Mail-Spam" oder "Spam" gesprochen,
obwohl der Begriff "Spam" eigentlich Newsartikel bezeichnet,
die inhaltsgleich in einer hohen Anzahl in einer oder mehr
Newsgruppen gepostet werden. Der Begriff "Spam" ist in der
Umgangssprache allerdings mittlerweile zu einem Schlagwort
für alle Arten von Werbung und anderen unerwünschten (Massen-)
"Belästigungen" geworden, egal, welches Medium (Mail, News,
IRC, Web, Fax, SMS usw.) dafür wie mißbraucht wurde.
* In der Newsgruppe sollten nach Möglichkeit keine kompletten
Mail-Spams veröffentlicht werden, weil die meisten Beteiligten
diese schon kennen und der Inhalt solcher Mail in den meisten
Fällen sowohl lang als auch uninteressant ist. In der Regel
sind nur die Header einer Mail relevant; falls über Einzelfälle
gesprochen wird, sollte man sich nach Möglichkeit auf die
Wiedergabe der notwendigen Teile des Headers beschränken. Vom
Inhalt der Mail sollten, wenn überhaupt, nur einzelne Zeilen
oder Absätze wiedergegeben werden, sofern sie für eine Diskussion
in der Gruppe von besonderer Bedeutung sind.
* Wenn ein Posting einen Teil eines Mail-Spams oder einen Header
enthält, sollte das Subject aus "[UBE]" gefolgt vom Originaltitel
des Mail-Spams bestehen (Beispiel: "[UBE] Want to attract that
special someone instantly?"). Diese Absprache soll zum einen
verhindern, daß zu einem Mail-Spam zig verschiedene Threads unter
unterschiedlichem Subject parallel in der Gruppe laufen, und zum
anderen ermöglichen, daß User solche Threads gezielt suchen oder
auch ignorieren können. Postings, die einfach nur den unveränderten
Originaltitel des Mail-Spams im Subject tragen, können zudem leicht
für Usenet-Spam gehalten und entsprechend gefiltert oder ignoriert
werden.
* Sollten im Header eines Mail-Spams Listen mit Mail-Adressen offenbar
ebenfalls betroffener Leute stehen, ist von einer Veröffentlichung
dieser Listen unbedingt abzusehen! Solche Listen sind oftmals sehr
lang, zudem geben sie u.U. Usenet-Scannern nur weiteres Adress-Futter.
Die Listen sollten also beim Veröffentlichen eines Headers unbedingt
entfernt (z.B. durch ein "To: [lange Liste]" ersetzt werden) oder
_mindestens_ verfremdet werden (z.B. durch Austausch des "@"-Zeichens
gegen ein "#"-Zeichen oder durch Einfügen von Leerzeichen). Sollten
die Listen mit Mail-Adressen besondere Merkmale aufweisen, die von
besonderer Bedeutung sein könnten oder die besonders auffällig sind
(z.B. "Alle Namen oder Adressen fangen mit 'A' an" oder "Nur GMX-
Adressen"), kann man dieses in seinem Posting gesondert z.B. im
begleitenden Text erwähnen.
D. FAQ - Frequently Asked Questions
===================================
D1. Übersicht über die Fragen
=============================
Frage 1:
* Was kann ich unternehmen, um keinen Mail-Spam zu bekommen?
Frage 2:
* Ist es sinnvoll, in News-Postings eine gefälschte oder veränderte
E-Mail-Adresse anzugeben, damit die Adresse nicht für Mail-Spam
verwendet werden kann?
Frage 3:
* Was kann ich tun, wenn ich Mail-Spam bekommen habe?
Frage 4:
* Wie kommt es, daß ich eine Mail bekomme, wenn in der To:-Zeile
oder Cc:-Zeile gar nicht meine Adresse steht?
Frage 5:
* Wie liest man einen Mail-Header?
Frage 6:
* Hilfe! Mein Mailserver / Webserver wird als Relay mißbraucht!
Was kann ich tun?
Frage 7:
* Hilfe! Meine Adresse oder meine Domain wird als Absender in Spam
mißbraucht! Was kann ich tun?
D2. Fragen mit Antworten
========================
Frage 1:
========
* Was kann ich unternehmen, um keinen Mail-Spam zu bekommen?
1. Antworten für User:
~~~~~~~~~~~~~~~~~~~~~~
A1: Als User kann man seinen Admin bitten, sich um eine
geeignete Abwehr zu kümmern (siehe A3). Oder man kann mit
verschiedenen Programmen die eigene Mail selbst nach be-
stimmten Kriterien filtern, damit man unerwünschte Post
erst gar nicht zu Gesicht bekommt oder sie von der "guten"
Post getrennt wird. Informiere Dich, ob es für Dein Betriebs-
system oder Deinen Mailer entsprechende Filter gibt.
* Spam e-mail blocking and filtering
http://spam.abuse.net/userhelp/#filter
* Filtering Mail FAQ
http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/
* Unix:
* Processing Mail with Procmail
http://www.ii.com/internet/robots/procmail/
* Procmail Quick Start
http://www.ii.com/internet/robots/procmail/qs/
* Procmail FAQ
http://www.iki.fi/era/procmail/mini-faq.html
* Procmail Links
http://www.iki.fi/era/procmail/links.html
* Catching Spam with Procmail
http://alcor.concordia.ca/topics/email/auto/procmail/spam/
* Joe Gross' Procmail Tutorial
http://www.stimpy.net/procmail/tutorial/
* Procmail Spam Filter: The Spam Bouncer
http://www.spambouncer.org/
* Procmail Spam Filter: Spamblock
http://www.belwue.de/projekte/spamblock.html
* Spamrc: Procmail Rules for Automatic Spam Detection
http://ceti.pl/~kravietz/spamrc/spamrc.php3
* Junkfilter: Junk Mail Filtration with Procmail
http://junkfilter.zer0.org/
* Filter out Chinese and Russian-language Spam
http://www.waltdnes.org/email/chinese/link.html
* Timo Salmi's Procmail Tips and Recipes
http://www.uwasa.fi/~ts/info/proctips.html
* pi's .procmailrc
http://piology.org/.procmailrc.html
* NL.linux.org Spamfilter
http://spamfilter.nl.linux.org/
* Email Addressing FAQ (How to use user+box@host addresses)
http://www.faqs.org/faqs/mail/addressing/
* Tagged Message Delivery Agent (TMDA)
http://tmda.net/
* Mailfilter - The Anti-Spam Utility
http://mailfilter.sourceforge.net/
* Unusual Research Home Page (Mailfilter)
http://www.unusualresearch.com/mailfilter/mailfilt.htm
* Mail-bounce E-mail returner
http://freshmeat.net/projects/mailbounce/
* SpamAssassin
http://spamassassin.org/
* Anleitung zu SpamAssassin (PDF)
http://www.unix-ag.sv.uni-saarland.de/Folien/SpamVirus/email.pdf
* Vipul's Razor - A collaborative spam filtering network
http://razor.sourceforge.net/
* Open Directory - Mail: Unix: Procmail
http://dmoz.org/Computers/Software/Internet/Clients/Mail/Unix/Procmail/
* rblfilter
http://psg.com/~brian/software/rblfilter/
* bogofilter
http://bogofilter.sourceforge.net/
* SpamProbe
http://spamprobe.sourceforge.net/
* Anti-Virus Procmail Recipes
http://www.mousetrap.net/~mouse/spam/rc/rc.virus.txt
* Windows:
* Open Directory - Windows: Tools: Anti Spam
http://dmoz.org/Computers/Software/Internet/Clients/Mail/Windows/Tools/Anti_Spam/
* Open Directory - Windows: Tools: Filtering
http://dmoz.org/Computers/Software/Internet/Clients/Mail/Windows/Tools/Filtering/
* Open Directory - Windows: Internet: Email: Spam Prevention
http://dmoz.org/Computers/Software/Shareware/Windows/Internet/Email/Spam_Prevention/
* Top 10 Anti-Spam Tools for Windows
http://email.about.com/cs/winspamreviews/tp/anti-spam.htm
* Product Reviews: Windows Anti-Spam Tools
http://email.about.com/cs/winspamreviews/
* SpamKiller
http://www.spamkiller.com/
* POP3 Scan Mailbox
http://www.kempston.demon.co.uk/smb/
* SpamNet (Outlook add-in)
http://cloudmark.com/products/spamnet/
* SpamPal
http://www.spampal.org.uk/
* Deutsche Hilfeseite für SpamPal für Windows
http://www.spampal.de/
* RegExFilter Plugin for SpamPal
http://www.slabihoud.de/spampal/
* Netscape:
* Deleting E-Mail with the Netscape Messenger Mail Filter
http://coldcure.com/html/no_spam.html
A2: Benutze spezielle Mail-Forwarder- und Mail-Filter-Dienste,
wenn Du Dich in der "Öffentlichkeit" (News, auf Webseiten etc.)
bewegst. Benutze nur diese Adressen in der Öffentlichkeit!
* eleven's eXpurgate spam-filter
http://www.spamfence.de/
* GMX - Global Message Exchange
http://www.gmx.de/
* Bigfoot
http://de.bigfoot.com/
* RBL-protected Mail Forwarding Accounts @stop.mail-abuse.org
https://stop.mail-abuse.org/
* SpamCop Email System for Individuals
http://mail.spamcop.net/individuals.php
* Mailinator
http://www.mailinator.com/
Erkundige Dich, ob Dein Zugangs- oder Mail-Anbieter Möglichkeiten
zur Verfügung stellt, Deine Mail schon beim Eintreffen resp. vor
dem Abholen auf dem Server zu filtern, zu sortieren und zu organi-
sieren:
* Snafu: snafu.mailfilter
http://www.snafu.de/content/produkte/mailfilter/
* Snafu: snafu.mailshield
http://www.snafu.de/content/produkte/mailfilter/aktuell/
* GMX: GMX-Mailfilter
http://www.gmx.de/antispamtipps
* WEB.DE Spam-Schutz
http://freemail.web.de/extern/spamfilter/info4.htm
Prüfe zudem sorgfältig, ob Du Deine Mail-Adresse nicht "unfrei-
willig" herausgibst. Viele Programme übergeben beim sogenannten
"anonymous FTP" die im Browser, Client oder System eingestellte
Mail-Adresse als Login-Information.
Zum Beispiel lautet im Unix-FTP-Client "ncftp" die entsprechende
Variable "anon-password":
anon-password
Specifies what to use for the password when logging
in anonymously. Internet convention has been to use
your E-mail address as a courtesy to the site admini-
strator. If you change this, be aware that some sites
require (i.e. they check for) valid E-mail addresses.
Auch für Downloads bietet es sich also an, eine gesonderte Mail-
Adresse einzurichten und zu konfigurieren, um Leuten und Systemen,
die diese eigentlich harmlose und nett gemeinte Eigenheit des
anonymous FTP ausnutzen, keine "wertvollen" Mail-Adressen mitzu-
teilen.
Eine weitere - oft übersehene - Möglichkeit, wie Adressen in die
Hände von Spammern geraten können, sind Web-Archive von Mailing-
listen. Viele Mailinglisten werden von den Dienste- oder Listen-
Betreibern oder auch Teilnehmern im WWW archiviert, um sie zum
Suchen und Nachschlagen bereitzustellen. Auch hier bietet wieder
eine eigentlich nett gemeinte Sache (auf die Frage, ob man Mailing-
listen überhaupt jedermann öffentlich zugänglich machen sollte und
"darf", soll hier nicht eingegangen werden) einen Angriffspunkt
für Adress-Sammler und Spammer. Manche Archive verfremden aus
diesem Grund die Mail-Adressen der archivierten Mail automatisch,
oftmals jedoch nach leicht erkennbaren und wiederkehrenden Mustern,
die leicht automatisch wieder rückgängig gemacht werden können.
Zudem betreffen diese Verfremdungen oftmals nur die From-Zeilen,
jedoch nicht die restlichen Header, den Body oder die Signatur.
Man sollte sich bei der Wahl der Adresse, mit der man sich in einer
Mailingliste subscribed, also u.U. Gedanken machen und erkundigen,
ob diese Mailingliste im WWW archiviert wird und ob und wie die
enthaltenen Adressen verfremdet oder entfernt werden. Im Zweifel
bietet es sich auch hier an, eine gesonderte Adresse zu benutzen,
die man z.B. nach besonderen Kriterien und Eigenheiten der Liste
filtern kann, um Spam auszusortieren.
Die gleiche Problematik betrifft natürlich auch Mail2News-Gates,
mit denen Mailinglisten-Mail in Newsartikel verwandelt und in
Newsgruppen gepostet wird. Viele Leute praktizieren Mail2News-
Gating zum Privatgebrauch auf dem heimischen Server, weil sich
insbesondere hochvolumige Mailinglisten im "Newsformat" besser
und schneller darstellen, bearbeiten und archivieren lassen; in
vielen Fällen geraten diese Newsartikel und Newsgruppen jedoch
absichtlich oder unabsichtlich in den "offenen" Usenet-Strom und
werden öffentlich verteilt.
Eine ebenfalls oftmals nicht bedachte Möglichkeit der ungewollten
Adress-Offenbarung ist eine, auf die der Adress-Inhaber kaum Ein-
fluss hat: Viele Viren und Würmer verschicken sich über die Adress-
Bücher der infizierten Systeme automatisch per Mail an weitere
Systeme. Dies ist - neben anderen Gefahren, die von einer Infektion
mit Viren oder Würmern ausgehen - oftmals besonders ärgerlich, da in
Adress-Büchern vielfach "gute" und interne Adressen von Privatleuten
oder Firmen stehen, die nicht für die Öffentlichkeit bestimmt waren,
sei es, um diese vor Mißbrauch und Spam zu schützen, aber auch, um
diese schlicht nicht unkontrolliert in die Öffentlichkeit geraten zu
lassen. Hier hilft nur der konsequente Schutz infektionsgefährdeter
Maschinen durch geeignete Viren- und Mail-Scanner und die Benutzung
möglichst ungefährdeter Software (Plain-Text-Mailer, Software ohne
Attachment-Ausführung u.ä.).
Weitere Informationen zum Thema "Woher haben die meine Adresse?!"
finden sich z.B. hier:
* Address Harvesting FAQ
http://www.private.org.il/harvest.html
* Unsolicited Commercial E-mail Research Six Month Report (03/2003)
http://www.cdt.org/speech/spam/030319spamreport.shtml
Oftmals haben Spammer jedoch überhaupt keine Listen mit konkreten
Adressen, die irgendwo eingesammelt wurden, sondern sie probieren
sich durch und "erraten" die Adressen ihrer Opfer:
Ob systematisch oder wild durcheinander werden Buchstaben- und
Zahlenkombinationen, Sammlungen von Localparts oder ganze Wörter-
bücher durchprobiert. Eine Methode, die die betroffenen Mailserver
und damit den Rest des Mailverkehrs dieser Server bis zur Unbenutz-
barkeit lahmlegen kann, da bei solchen "Brute Force Spamming"-
Attacken mitunter innerhalb kürzester Zeit Abertausende von SMTP-
Kommandos abgesetzt werden.
In der Praxis werden solche Spam-Attacken besonders gerne gegen
Backup-/Secondary-MXe gefahren (für nähere Ausführungen dazu siehe
unter Frage 3 den Abschnitt "Das Ding mit dem Backup-MX"), um den
"Output" zu maximieren.
2. Antworten für Server-Administratoren:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A3: Als Admin eines Mailservers kann man verschiedene Filter
verwenden, die Mail, die bestimmten Kriterien entspricht,
nicht annehmen und/oder weiterleiten. Ob und welche Filter-
möglichkeiten bestehen, hängt von der eingesetzten Software
ab.
Allgemeines:
* Blocking by MTAs
http://spam.abuse.net/adminhelp/mail.shtml#relay
Exim:
* The Exim Filter
http://www.exim.org/exim-html-3.30/doc/html/filter.html
http://www.exim.org/exim-html-4.10/doc/html/filter.html
* Filtering Email with Perl and Exim
http://www.etla.org/articles/filter/
* exiscan - An email content scanner for the exim MTA
http://duncanthrax.net/exiscan/
Sendmail:
* Using check_* in Sendmail 8.8
http://www.sendmail.org/~ca/email/check.html
* Using check_* in Sendmail 8.9
http://www.sendmail.org/~ca/email/chk-89.html
* Debugging check_* in Sendmail 8.8/8.9
http://www.sendmail.org/~ca/email/chk-dbg.html
* Anti-UBE Features in Sendmail 8.10/8.11
http://www.sendmail.org/~ca/email/chk-810.html
* Extended spam filter: check_local 5.4 for sendmail 8.12
http://www.digitalanswers.org/check_local/
* E-mail filtering techniques
http://www.arachnoid.com/lutusp/antispam.html#filter
* Sendmail's Milter (Content Filter API)
http://www.sendmail.com/partner/resources/development/milter_api/
* milter.org
http://www.milter.org/
* spamcheck.milter.pl
http://www.megacity.org/software_downloads/spamcheck.milter.txt
* Sendmail::Milter (Perl Module)
http://sourceforge.net/projects/sendmail-milter/
Postfix:
* Postfix Configuration - UCE Controls
http://www.postfix.org/uce.html
Qmail:
* Anti-Spam Techniques and Code
http://qmail.mirrors.Space.Net/top.html#spam
Hamster:
* Filtersammlung
http://spamabwehr.sakrak.net/spam-filter/
Lotus Notes:
* Notes-based support for RBL, DUL and RSS
http://www.idgnews.net/SpamFilter/
Desweiteren besteht die Möglichkeit, bestimmte Blacklists
("schwarze Listen") zu benutzen, in denen Mailserver stehen,
von denen besonders viel unerwünschte Mail ausgeht, da sie
durch ihre Betreiber nicht oder nicht ausreichend gegen
Mißbrauch geschützt wurden oder deren Betreiber Spam passiv
oder aktiv unterstützen (z.B. durch Duldung von spammenden
Kunden oder gar eigenhändiges Aussenden von Spam).
* Blacklists Compared
http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html
* Open Directory - Computers: Internet: Abuse: Spam: Blacklists
http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/
* ip4r (RBL-style) DNS lookups - Blacklist-Übersicht
http://www.declude.com/JunkMail/Support/ip4r.htm
* RBL - Realtime Blackhole List
http://mail-abuse.org/rbl/
* DUL - Dial-Up User List
http://mail-abuse.org/dul/
* RSS - Relay Spam Stopper
http://mail-abuse.org/rss/
Wichtiger Hinweis zu RBL, DUL und RSS:
* Changes to Subscription Policies Effective 7/31/2001
http://mail-abuse.org/subscription.html
http://mail-abuse.org/feestructure.html
* ORDB.org - Open Relay Database
http://www.ordb.org/
* njabl.org - Not Just Another Bogus List
http://www.njabl.org/
* Pan-Am Dynamic List (PDL) Project Home Page
http://www.pan-am.ca/pdl/
* SpamCop Blocking List Information
http://spamcop.net/bl.shtml
* Cluecentral's RBL lists
http://www.cluecentral.net/rbl/
* The Spamhaus Project
http://www.spamhaus.org/
Andere Filter- und Blocking-Ansätze:
* rfc-ignorant.org
http://www.rfc-ignorant.org/
* Distributed Checksum Clearinghouse
http://www.rhyolite.com/anti-spam/dcc/
* SPEWS - Spam Prevention Early Warning System
http://www.spews.org/
* Distributed Sender Boycott List
http://dsbl.org/
* NML - Non-confirming Mailing List Database
http://mail-abuse.org/nml/
* MessageWall SMTP Proxy
http://messagewall.org/
* BCware NoSPAM SMTP Proxy Daemon
http://www.bcwaresystems.com/nospam/
* POPFile - Automatic Email Classification
http://sourceforge.net/projects/popfile/
* SPF - Sender Policy Framework
http://spf.pobox.com/
* RMX - Reverse MX
http://www.danisch.de/work/security/antispam.html
* SURBL - Spam URI Realtime Blocklist
http://www.surbl.org/
Gedanken über eine grundsätzliche Veränderung des Systems
Mail durch Umkehrung der Mail-Lagerung (Ansatz: "Mail storage
is the sender's responsibility.") finden sich hier:
* Internet Mail 2000
http://cr.yp.to/im2000.html
Lesenswerte Abhandlungen von Paul Graham (Filterung von Spam u.ä.):
* Paul Graham
http://www.paulgraham.com/
A4: Zur serverseitigen Behinderung eines massiv einliefernden
Rechners kann der Admin eines Mailservers eine sogenannte "Teer-
grube" installieren. Damit wird der Rechners des Versenders
künstlich ausgebremst, so daß er weniger Mail als normal aus-
liefern kann.
Details dazu finden sich in der Teergruben-FAQ, die regelmäßig
in de.admin.net-abuse.mail gepostet wird und auch im WWW zu
finden ist:
* FAQ: Teergruben gegen Spam
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html
A5: Zum Thema "Adressen-Sammeln von Webseiten und was man da-
gegen tun kann" gibt es hier eine sehr gute Informationsquelle:
* Protect your Webserver from Spam Harvesters
http://www.sendfakemail.com/fakemail/antispam.html
In diesem Kontext einige Informationen über sogenannte "Web
Wanderers", "Crawlers" oder "Spiders":
* The Web Robots Pages
http://www.robotstxt.org/wc/robots.html
* Suchmaschinen und robots.txt
http://www.dodabo.de/netz/suchmaschinen.php
Frage 2:
========
* Ist es sinnvoll, in News-Postings eine gefälschte oder veränderte
E-Mail-Adresse anzugeben, damit die Adresse nicht für Mail-Spam
verwendet werden kann?
A: Nein, ganz im Gegenteil! Das (Ver)Fälschen von Adressen, also
das Benutzen von sogenannten "Spam-Blocks", kann zwar in seltenen
Fällen Schutz vor unerwünschter Mail bieten, allerdings verstößt
es gegen die technischen, administrativen und sozialen Regeln und
Funktionsmechanismen des Mediums Mail und macht es somit nur noch
weiter unbrauchbar. Zudem geht es zumeist auf Kosten anderer Leute
und ihrer Ressourcen.
Unter Umständen landen die durch das Manipulieren erzeugten Bounces
(automatische "Rückläufer" einer Mail zum Absender oder Betreuer des
Mailsystems bei Zustellungsproblemen) nämlich sogar beim Postmaster
Deines eigenen Providers oder bei einem hilfsbereiten Mitmenschen,
der Dir eigentlich nur eine Antwort auf einen Usenetartikel schicken
wollte. Diese werden darüber ganz sicher nicht erfreut sein, wenn
sich ein potentielles technisches Problem (Bounce) beim näheren Hin-
sehen als mutwilliges Fehlverhalten eines Users herausstellt, für
das sie soeben ihre Zeit verschwendet haben. Das (Ver)Fälschen von
Adressen bringt also nur sehr viel Ärger und ist rücksichtsloses,
netzfeindliches und kommunikationszerstörendes Verhalten.
Das (Ver)Fälschen von Adressen ist keine Lösung für das Problem der
unerwünschten Mail, da es die eigentliche Problematik nur auf andere
verlagert, und es ist - wie bereits gesagt - zudem ein Verstoß gegen
die technischen Grundregeln des Netzes.
Rechne also damit, daß Du Dich, wenn Du Spam-Blocks benutzt, ziemlich
schnell unbeliebt machen wirst und Dir kaum jemand mehr schreiben mag.
Darüberhinaus hat sich in der Praxis gezeigt, daß Spammer durchaus
in der Lage sind, Spam-Blocks mittels geeigneter Methoden automatisch
zu entfernen.
Ausführliche Erklärungen zum Thema "Falsche E-Mail-Adressen" findest
Du in der Mini-FAQ von Carsten Gerlach. Sie wird regelmäßig in danam
(de.admin.net-abuse.mail) gepostet und ist im WWW unter folgender URL
zu finden:
* Mini-FAQ: Falsche E-Mail-Adressen
http://home.pages.de/~gerlo/falsche-email-adressen.html
Statt ge- oder verfälschte Adressen zu benutzen, sollte man sich
besser zusätzliche Adressen (vgl. Frage 1, A2) anlegen und diese
benutzen. Z.B. kann man verschiedene Adressen für From und Reply-To
verwenden. Die Praxis zeigt, daß der größte Teil der unerwünschten
Mail an die From-Adressen geht, während "echte" Antworten in der
Regel an die Reply-To-Adresse gehen, da ein gesetztes Reply-To
von "normalen" Clients technisch höher priorisiert wird als eine
From-Adresse. Ausnahmen bestätigen natürlich die Regel. Wenn man
mehrere solcher Adress-Sätze geschickt und gezielt einsetzt und
kombiniert, kann man sogar durchaus ermitteln, wo der Spammer die
Adressen eingesammelt hat.
* Address Munging Considered Harmful
http://www.interhack.net/pubs/munging-harmful/
Frage 3:
========
* Was kann ich tun, wenn ich Mail-Spam bekommen habe?
A: Eine eiserne Regel gilt für alle unerwünschte Mail:
NIEMALS irgendwelche "Remove"-Antworten oder Reaktionen an den
Absender oder irgendwelche im Text angegebenen Adressen zurück-
schicken! Dies gilt auch dann, wenn es sich scheinbar um einen
"harmlosen" Newsletter handelt. Wenn _Du_ ihn nicht angefordert
hast, ist es unverlangte Mail. Wenn jemand anders Dich in die
Verteilerliste eingetragen hat, bleibt es dennoch unverlangte
Mail, selbst wenn dieser jemand aus Deinem Bekanntenkreis kommen
sollte. Seriöse Mailinglistenbetreiber verifizieren einen Sub-
scription-Request beim Inhaber der Adresse, bevor sie ihn ein-
tragen. Glaube auch niemals Behauptungen, daß die erhaltene Mail
von irgendwelchen US-Bills, EU-Richtlinien o.ä. gedeckt oder
legalisiert sei. Das ist in fast allen Fällen frei erfunden.
Als Beispiel sei die "Bill S.1618" genannt, die in vielen Spams
angeführt wird:
* "This is not Spam!" oder - Die Wahrheit über Senate Bill S.1618
http://www.bastisoft.de/misc/s.1618.html
Meistens sind die in Spam-Mail als Absender oder Reply-To an-
gegebenen Adressen sowieso ungültig oder gefälscht, so daß man
bei einer Antwort nur einen Bounce zurückbekommen würde. Sollte
die angegebene Adresse gültig sein, wäre eine Antwort noch fataler,
denn durch die Antwort kann der Spammer die Adresse dann sicher
als "echt und wird gelesen" einstufen. Solche Adressen sind in
Spammerkreisen natürlich sehr wertvoll, und eine solche Adress-
bestätigung dürfte einen weiteren Anstieg der Flut der uner-
wünschten Mail zur Folge haben.
Ebenso ist Vorsicht geboten, wenn in der Mail URLs genannt
werden, bei denen Parameter übergeben werden (als Beispiel:
"http://www.spam.bogus/coolstuff/freedl?8346"), auch dies
könnte der Verifizierung von Mail-Adressen dienen. Das gilt
auch für Mail, die Links zu angeblich auf den Download wart-
enden elektronischen Postkarten ("E-Cards"), Software-Updates
o.ä. enthält, auch hier kann leider manchmal Mißtrauen ange-
bracht sein. Prüfe solche Offerten im Zweifel wenigstens soweit
irgend möglich auf Plausibilität und Seriosität, bevor Du die
genannte URL besuchst.
Manchmal befinden sich am Ende eines Spams unscheinbare Zahlen-
Ziffern-Kombinationen. Diese dienen höchstwahrscheinlich eben-
falls dazu, bei direkten Reaktionen die Mail-Adresse zu veri-
fizieren. Sie sollten daher unbedingt bei einer direkten Reaktion
weggelassen werden.
Sollte der Spam im Header Listen mit Mail-Adressen offenbar
ebenfalls betroffener Leute enthalten, achte bei eventuellen
Reaktionen unbedingt darauf, daß Deine Mail nicht an all diese
Leute geht und sie so unnötig involviert oder belästigt!
Sich beim Versender selbst über unerwünschte Mail zu beschweren,
ist in der Regel natürlich sinnlos und sogar kontraproduktiv.
Also muß man dessen Provider und/oder Uplink suchen und sich
dort beschweren.
Beschwerden über unerwünschte Mail und die dazu notwendigen
korrekten Header-Analysen sind keine Sache, die man in 5 Minuten
lernen kann, und es gibt auch kein einfaches "Kochrezept" dafür,
zumal gerade bei Werbemüll-Mail auch fast immer mit Header-
Fälschungen gearbeitet wird.
Da ist es dann die "Kunst", zu sehen, welchen Headern man als
"echt" trauen kann (das sind zumeist die Zeilen, die im Bereich
des eigenen Mailservers oder dem des Providers liegen) und welche
man als "falsch" überhaupt nicht in seine Analyse einbeziehen
kann. Jeder Mail-Header muß erneut und gesondert betrachtet werden.
Aber natürlich kann man seine Erfahrungen und bestimmte Dinge von
der einen Mail auf die andere übertragen.
Ob Beschwerden über unerwünschte Mail sinnvoll sind, hängt sehr
davon ab, woher die jeweilige Mail kam. Beschwerden über Mail aus
den meisten europäischen Ländern sind fast immer sinnvoll. Da hat
man gute Chancen, auch etwas zu erreichen (wie z.B. Account-Sperr-
ungen oder sogar juristische Konsequenzen, dazu unten mehr). Bei
Mail z.B. aus Asien bekommt man auf Beschwerden oftmals keine
Antwort oder nur ein automatisch generiertes Trouble-Ticket, dem
jedoch keinerlei Konsequenzen für den Spammer folgen, weswegen
diese Automatismen von geplagten Spam-Empfängern auch "Ignore-Bots"
genannt werden. Rühmliche und unrühmliche Ausnahmen gibt es aber
natürlich überall.
Wenn Du also lernen willst, Mail-Header richtig zu deuten, Beschwerde-
Adressen zu finden, Erfolgsaussichten bei Beschwerden beurteilen zu
können und wissen willst, was Du noch alles tun kannst (und auch, was
Du NICHT tun solltest), um Dich gegen die unerwünschte Werbeflut zu
wehren, bedeutet das etwas Arbeit für Dich:
Abuse-Newsgruppen lesen!
~~~~~~~~~~~~~~~~~~~~~~~~
Das deutschsprachige de.admin.net-abuse.mail (Du badest vermutlich
gerade Deine Hände darin) ist "Pflichtlektüre", man kann da sehr viel
lernen. Die englischsprachigen Gruppen unter news.admin.net-abuse.*
sind nur bedingt zu empfehlen, da sehr voll, Reinschauen schadet aber
nicht. Solche Gruppen sind - sofern noch nicht geschehen - auch eine
gute Gelegenheit, die Kill- und Score-File-Mechanismen des eigenen
Newsreaders kennenzulernen und ausgiebig zu testen. ;-)
FAQs lesen!
~~~~~~~~~~~
Jaja, Du bist ja schon dabei. ;-) Eine Auswahl an Texten, die wiederum
viele Quer- und Weiterverweise sowie Berge von Erklärungen und guten
Tips liefern:
* FAQ: E-Mail-Header lesen und verstehen
http://www.th-h.de/faq/headrfaq.html
* The Net Abuse FAQ
http://www.cybernothing.org/faqs/net-abuse-faq.html
* The Email Abuse FAQs
http://members.aol.com/emailfaq/
* The alt.spam FAQ or "Figuring out fake E-Mail & Posts"
http://ddi.digital.net/~gandalf/spamfaq.html
* news.admin.net-abuse.email FAQ
http://www.spamfaq.net/
http://www.spamfaq.net/otherfaqs.shtml
* Fighting E-Mail Spammers
http://eddie.cis.uoguelph.ca/~tburgess/local/spam.html
* Frequently asked questions about spam
http://spam.abuse.net/faq/
* Spam - Ursache, Auswirkungen und Bekämpfung (Vortrag)
ftp://ftp.belwue.de/pub/doc/spamvortrag/index.html
* Spam Address FAQ -- How To Fight Back
http://www.iki.fi/era/spam/faq/spam-addresses.html
* Spam - Die E-Mail-Plage
http://portale.web.de/Internet/Spam/
* Mini-FAQ "Unerwünschte Werbemails"
http://www.usenet-abc.de/tol/spam.htm
* The Spammers' Compendium
http://www.jgc.org/tsc/
Tools und Hilfsmittel
~~~~~~~~~~~~~~~~~~~~~
Mache Dich mit den Tools "nslookup", "dig", "traceroute", "ping"
und - ganz wichtig - "whois" vertraut. Die Kommandos heißen unter
Unix so. Auf Unix-Maschinen kann ein Anleitungstext ("man page")
zu den Kommandos mit dem "man"-Befehl aufgerufen werden. Wenn Du
ein Nicht-Unix benutzt, suche Dir die entsprechenden Gegenstücke
zu Deinem OS; einige der Tools sind auch im WWW in Web-Seiten ein-
gebaut verfügbar. In der "E-Mail-Header lesen und verstehen"-FAQ
steht ebenfalls einiges dazu. Diese Tools sind nicht nur für die
Spam-Analyse sinnvoll und nützlich.
* CyberKit - Tools for Windows 9x/NT/2000/ME/XP
http://www.cyberkit.net/
http://www.gknw.com/mirror/cyberkit/
Nützliche Informationen, Linklisten und Hilfsmittel:
* Open Directory - Computers: Internet: Abuse: Spam
http://dmoz.org/Computers/Internet/Abuse/Spam/
* Yahoo! Directory: Email: Spam
http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networking/Email/Spam/
* Spam Tracking Page
http://www.rahul.net/falk/
* UXN Spam Combat
http://combat.uxn.com/
* www.DNSstuff.com
http://www.dnsstuff.com/
* Spam Links and Help
http://www.paladincorp.com.au/unix/spam/links/
* Generische Abfrage von whois-Datenbanken
http://www.iks-jena.de/cgi-bin/whois
* Some Abuse Reporting Tools
http://www.abuse.net/tools.html
* nadc - Complaint Composer (Perl)
ftp://ftp.belwue.de/belwue/software/nadc
* Ricochet (spam tracing and reporting)
http://vipul.net/ricochet/
* Abuse (spam tracing and reporting)
http://spam-abuse.sourceforge.net/
* SamSpade.org
http://www.samspade.org/
* Allwhois.com
http://www.allwhois.com/
* Whois Data Problem Report (InterNIC)
http://www.internic.org/cgi/rpt_whois/rpt.cgi
* Geektools - Spam Tools, Traceroute
http://www.geektools.com/
* traceroute.org
http://www.traceroute.org/
* mtr - Combines the functionality of "traceroute" and "ping"
http://www.BitWizard.nl/mtr/
* spamcop.net
http://spamcop.net/
* spamcop.net-Statistiken
http://spamcop.net/spamstats.shtml
* rblcheck (helps you perform lookups in RBL-style)
http://rblcheck.sourceforge.net/
* rblcheck (Perl)
http://www.salesianer.de/util/rblcheck.pl
* Multi-RBL check
http://rbls.org/
* openrbl.org: DNSBL Lookup
http://www.openrbl.org/
* DNSBL database check
http://www.moensted.dk/spam/
* Another DNSBL database check
http://relays.osirusoft.com/cgi-bin/rbcheck.cgi
* Tips and help for regular users
http://spam.abuse.net/userhelp/
* SpamArchive.org
http://spamarchive.org/
* Script Collection to Smoke Spam(ers) in Pipes
http://fn.neuroflex.de/SCSSP/
* Proxypot
http://world.std.com/~pacman/proxypot
* Reporting Dutch Spam
http://news.spamcop.net/pipermail/spamcop-list/2003-November/064952.html
* Spam Reporting Addresses
http://banspam.javawoman.com/report3.html
* Anti-Spam Research Group (ASRG)
http://asrg.sp.am/index.shtml
* Spam Links
http://spamlinks.net/spamlinks.htm
Schaue Dir die Web-Seiten von abuse.net an!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Welcome to the Network Abuse Clearinghouse
http://www.abuse.net/
Dort finden sich die Seiten des "Network Abuse Clearinghouse";
sie helfen enorm bei der Suche nach dem richtigen Ansprechpartner
für eine Beschwerde.
Es folgen einige zusätzliche Ausführungen zum Thema "Finden des
richtigen Ansprechpartners".
1. Eine kurze Übersicht der Abuse-Adressen rund um die Domains
von T-Online und der Deutschen Telekom, da dies häufig Gegen-
stand von Verwirrung und Nachfragen ist:
* t-dialin.net (T-Online-Dialups):
abuse@t-online.com
abuse@t-online.de
abuse@t-dialin.net
* Andere Telekom-Domains und -IPs, Reseller-Dialups etc.:
abuse@t-ipnet.de
2. Das Ding mit dem Backup-MX:
Ein MX (Mail Exchange) ist ein Eintrag im DNS (Domain Name Service),
der angibt, welche Mailserver zuständig sind, Mail für eine Domain
oder einen Rechner anzunehmen.
Dabei unterscheidet man zwischen Mailservern, die für die finale
Zustellung zuständig sind (sogenannte Primary- oder höchste MXe)
und Mailservern, die als "Fallnetz", als Zwischenspeicher für die
Primary-MXe arbeiten (sogenannte Backup-, Fallback- oder Secondary-
MXe).
Lässt man sich die MXe für eine Domain oder einen Rechner anzeigen,
sieht man, daß ihnen Zahlen zugeordnet sind, die sogenannten Priori-
täten:
snafu.de MX 5 mail.snafu.de
snafu.de MX 10 mail.unlisys.net
Generelle Erklärungen zu MXen und Prioritäten:
* Je kleiner die Zahl, desto höher die Priorität. Die Zahl an
sich ist bedeutungslos, es geht nur um grösser oder kleiner.
* Es kann mehrere MXe gleicher Priorität geben. Es kann für eine
Domain oder einen Rechner sowohl mehrere Primary-MXe (gleicher
Priorität) als auch mehrere Backup-MXe (gleicher oder unter-
schiedlicher Priorität) geben.
* Das Vorhandensein von Backup-MXen ist optional.
Obige Ausgabe bedeutet also, daß "mail.snafu.de" der Primary-MX
(Priorität 5) und "mail.unlisys.net" der Backup-MX (Priorität 10)
für die Domain "snafu.de" ist.
Die Zustellung einer Mail läuft im Normalfall so ab, daß zuerst
versucht wird, auf den Primary-MX zuzustellen. Falls dieser nicht
erreichbar ist, wird - so vorhanden - eine Zustellung auf den oder
die Backup-MXe versucht, die die Mail zwischenspeichern und an den
Primary-MX weiterleiten; ist kein MX erreichbar, verbleibt die Mail
in der Queue des sendenden Systems.
Das System der Backup-MXe wird von Spammern gerne in verschiedener
Hinsicht mißbraucht:
Da Backup-MXe meist nicht über die Account- und Alias-Listen der
Primary-MXe verfügen, sondern einfach alle Mail für eine Domain
oder einen Rechner annehmen und an die Primary-MXe weiterleiten,
wird von Spammern gezielt versucht, auf die Backup-MXe zuzustellen,
um die Quote der direkten Rejects zu minimieren und die Rejects
wegen ungültiger Adressen auf den Dialog zwischen Backup-MX und
Primary-MX zu verlagern.
Zudem sollen durch die gezielte Zustellung auf die Backup-MXe
mögliche Blacklists und Filter auf den Primary-MXen umgangen
werden, da Backup-MXe oftmals keine oder andere Blacklists und
Filter fahren als die Primary-MXe, und die finale Zustellung der
Mail von Backup-MX auf Primary-MX (und nicht von Spammer auf
Primary-MX) stattfindet, wodurch hostbasierte Blacklists und
Filter der Primary-MXe ausgehebelt werden.
Durch die gezielte Zustellung auf die Backup-MXe soll desweiteren
versucht werden, den wahren Ursprung einer Mail zu verschleiern,
da durch die Backup-MXe eine weitere Ebene von beteiligten Servern
im Header eingezogen wird, die insbesondere bei ungeübteren Nutzern
Header-Analysen erschwert und somit Beschwerden, Blacklisting etc.
auf die Backup-MX-Systeme lenkt.
Deswegen ist es sehr wichtig, bei der Suche nach dem Ansprechpartner
für eine Beschwerde den Header sauber zu analysieren, um sich nicht
bei den oder über die eigenen Backup-MX-Systemen zu beschweren.
Ansonsten
~~~~~~~~~
Postmaster und Support Deines Providers sind primär dafür da, Dir
bei technischen Problemen zu helfen und dafür zu sorgen, daß Du
Deine Post bekommst, und nicht, um herauszufinden, wer Dir Post
schickt, die Du nicht willst. Sie haben nichts mit dem zu tun,
was Dir von fremden Systemen geschickt wird.
Sofern der Verursacher nicht bei Deinem eigenen Provider sitzt,
können Postmaster und Support Deines Providers genauso wenig tun
wie jeder andere, da sie weder die entsprechenden Logs noch die
Möglichkeit von Maßnahmen wie Abmahnung oder Accountsperre haben.
So etwas kann nunmal nur der, bei dem der Verursacher seinen
Account/Zugang hat.
Wenn Du trotz Studium von obigen Tips und Anleitungen nicht
weiterkommst, kannst Du natürlich als letzte Möglichkeit den
Postmaster und Support Deines Providers fragen, ob er Dir bei
einer Headeranalyse und bei der Ermittlung des betreffenden
Ansprechpartners für eine Beschwerde behilflich sein könnte.
Benutze diese Möglichkeit aber nicht leichtfertig und sei auch
nicht enttäuscht, wenn Du keine Antwort bekommst!
Wenn Du nicht sicher bist, ob Deine Recherche-Ergebnisse bei
der Suche nach der richtigen Beschwerde-Adresse korrekt sind,
kannst Du in dieser Newsgruppe (de.admin.net-abuse.mail) die
entsprechenden Fragen stellen. Beachte dazu aber bitte die oben
bereits ausgeführten "Hinweise zur Gruppennutzung"!
Gesetze, Politik und Spam
~~~~~~~~~~~~~~~~~~~~~~~~~
Auch im "wirklichen Leben" hat die Mail-Spam-Problematik ihre
Spuren hinterlassen. Gerichte haben Spam-Versender verurteilt,
Abgeordnete haben über Richtlinien und Gesetze abgestimmt. Hier
einige Seiten, die Dir den Einstieg in die Thematik erleichtern
können:
* Compilation of Laws related to "Spam"
http://www.spamlaws.com/
* Google Web Directory - Society > Issues > Fraud > Internet
http://directory.google.com/Top/Society/Issues/Fraud/Internet/
* CAUCE - Coalition Against Unsolicited Commercial Email
http://www.cauce.org/
* EuroCAUCE - European Coalition Against Unsolicited Commercial Email
http://www.euro.cauce.org/
* Stimm gegen SPAM!
http://www.politik-digital.de/spam/
Die letztgenannte Seite sorgte durch die Online-Petition "Stimm
gegen SPAM!", die an die Abgeordneten des Europäischen Parlaments,
die Abgeordneten in den nationalen Parlamenten und an die Werbe-
wirtschaft gerichtet war und bei der mehrere zehntausend virtuelle
"Unterschriften" zusammenkamen, für einiges Aufsehen in den Medien.
In Österreich stellt das unverlangte Zusenden von Massen- oder
Werbe-Mail seit Juli 1999 eine mit bis zu 500.000 Schilling (das
entspricht ungefähr 70.000 DM oder 36.000 EUR) Strafe bedrohte
Handlung dar. Informationen dazu finden sich zum Beispiel unter
folgenden URLs:
* VIBE.AT - Verein für Internet-Benutzer Österreichs
http://www.vibe.at/
* Parlamentarische Materialien
http://www.parlinkom.gv.at/pd/pm/XX/I/texte/020/I02064_.html
In der Schweiz ist eine Regelung analog der "österreichischen"
Richtung in der parlamentarischen Beratung.
* Motion Simonetta Sommaruga
http://www.parlament.ch/afs/data/d/gesch/2000/d_gesch_20003393.htm
* Neues Medium - Neue Fragen ans Recht
http://www.ofj.admin.ch/themen/ri-ir/internet/rf-internet-d.pdf
* Merkblatt über unerwünschte E-Mail-Werbung
http://www.edsb.ch/d/doku/merkblaetter/spam.htm
Eine Vorlage für ein Auskunftsbegehren gemäß Artikel 8 des
schweizerischen Datenschutzgesetzes (DSG) sowie Links zu den
relevanten Gesetzestexten finden sich hier:
* Davids freundliche Folterfragen (DFFF)
http://www.astrum.ch/netsec/dsg-auskunft.txt
* Gesetze und andere Erlasse (Schweiz)
http://www.edsb.ch/d/gesetz/schweiz/index.htm
* Rechte bei der Bearbeitung von Personendaten (Schweiz)
http://www.edsb.ch/d/doku/leitfaeden/pdaten_recht/index.htm
Die nationale Koordinationsstelle zur Bekämpfung der Internet-
Kriminalität (KOBIK):
* Meldestelle Internet-Kriminalität
http://www.cybercrime.admin.ch/
Die Swiss Internet User Group (SIUG) versucht, dem Themenbereich
Spam/UBE/UCE eine Öffentlichkeit zu geben, u.a. durch ein Positions-
papier, diverse Pressemitteilungen sowie durch direkte Kontakte
mit Politikern und Behörden.
* SIUG - Swiss Internet User Group
http://www.siug.ch/
* Positionspapier zum Thema "Spam"
http://www.siug.ch/positionen/SIUG-Spam.shtml
* Pressemitteilungen
http://www.siug.ch/presse/
Im Frühling 2001 wurde die CD-ROM "BlackBook 2000" von Mitgliedern
der Vereine trash.net und SwordLord entschlüsselt. Der Vertreiber der
CD-ROM strengte gegen die Veröffentlichung der Ergebnisse ein zivil-
rechtliches Verfahren an, welches noch hängig ist. Durch eine vor-
sorgliche Verfügung wurden die Informationen vom ursprünglichen Ort
(http://bbook.trash.net/) entfernt.
Ein Mirror und weitere Informationen sind hier verfügbar:
* Informationen zum Spam-Tool "Black Book"
http://www.geocities.com/bbook2k/
* Informationen zum Thema Spam
http://www.trash.net/~roman/
Zur Finanzierung dieses Falles und zukünftiger ähnlich gelagerter
Fälle wird ein Spendenfonds eingerichtet:
* Vorläufige Informationen Rechtsfonds
http://www.siug.ch/presse/Presse.20010518.html
Roman Racine zum Stand der Dinge im Juli 2002 (nahezu unverändert
auch noch Stand im März 2003):
| Das bisherige Ergebnis nach über einem Jahr: Kein Gericht hat
| bisher irgendetwas entschieden. Als einzige Instanz (die aller-
| dings keine rechtskräftigen Entscheide fällen kann) hat der Eidg.
| Datenschutzbeauftragte entschieden und seine Empfehlung im heute
| erschienenen Tätigkeitsbericht [1] veröffentlicht [2], der sich
| weitgehend mit meiner Ansicht deckt und ziemlich genau das be-
| inhaltet, was ich im Moment nicht publizieren darf. (Kurioser-
| weise bin ich durch richterliche Verfügung verpflichtet, die in
| der Empfehlung anonymisierten Namen unter dem in der Empfehlung
| angegebenen Link zu veröffentlichen.) Der Tätigkeitsbericht
| befasst sich ausserdem mit einem anderen Schweizer Spammer, der
| einigen von euch auch wohlbekannt sein dürfte [3].
|
| [...]
|
| [1] Tätigkeitsbericht des Eidg. Datenschutzbeauftragten:
| http://www.edsb.ch/d/doku/jahresberichte/tb9/index.htm
| [2] Empfehlung Black Book:
| http://www.edsb.ch/d/doku/empfehlungen/blackbook.htm
| [3] Abschnitt zum Thema Spam:
| http://www.edsb.ch/d/doku/jahresberichte/tb9/kap9.htm#82
Quelle: <afpjtl$geom7$1@ID-114304.news.dfncis.de>
In Deutschland waren in der Vergangenheit insbesondere bei un-
erwünschter Mail von Verursachern aus Deutschland rechtliche
Schritte erfolgreich. Insofern sollte man in solchen Fällen u.U.
durchaus in Erwägung ziehen, den Verursacher abmahnen oder sogar
verklagen zu lassen. Bei Privatpersonen können Verbraucherzentralen
wichtige Ansprechpartner sein.
Einen juristischen Ein- und Überblick zum Themenbereich "Recht-
liche Möglichkeiten" bietet die FAQ von RA Dr. Ackermann:
* FAQ zur Abwehr von Spam
http://www.dr-ackermann.de/spam/faq.htm
Ein Musterentwurf, mit dem man einen Verursacher aus Deutschland
bezugnehmend auf das deutsche Bundesdatenschutzgesetz (BDSG) an-
gehen kann, findet sich hier:
* BDSG-Aufforderung (FFFF)
http://www.ulm.ccc.de/chaos-seminar/spam/spam-bsdg-aufforderung.html
* Alternative Fassung von Framstags freundlichem Folterfragebogen (T5F)
http://www.schnappmatik.de/TFFFFF/
Sollte der Empfänger eines solchen Auskunftsverlangens nicht
reagieren, so kann es unter Umständen sinnvoll sein, sich bei
der entsprechenden Datenschutz-Aufsichtsbehörde zu beschweren
(örtliche Zuständigkeit beachten!):
* Die Aufsichtsbehörden für den Datenschutz
http://www.datenschutz-berlin.de/sonstige/behoerde/aufsicht.htm
Die traurigen Ergebnisse und die Ausführungen zu rechtlichen Regel-
ungen und Entwicklungen einer Studie im Auftrag der Europäischen
Kommission (Februar 2001) sind hier nachzulesen:
http://europa.eu.int/comm/internal_market/de/dataprot/studies/spam.htm
Zum Themenbereich "seriöses E-Mail-Marketing" finden sich hier
Informationen:
* Permission Marketing Policy
http://www.absolit.com/Permission-Marketing-Policy/
Bei Spam aus den USA kann u.U. die FTC (Federal Trade Commission)
ein Ansprechpartner sein:
* Federal Trade Commission
http://www.ftc.gov/
Eine schöne Glosse zum Thema "Spam" hat Thomas Bindewald geschrieben;
sie überträgt die Problematik anschaulich und sehr treffend in Bilder
und Situationen, die auch "Nicht-Netizens" leicht verstehen und nach-
vollziehen können:
* Wie lästig ist unerwünschte Mail?
http://www.bindewald.net/texte/badmail.htm
Frage 4:
========
* Wie kommt es, daß ich eine Mail bekomme, wenn in der To:-Zeile
oder Cc:-Zeile gar nicht meine Adresse steht?
A: Hierzu hatte Heiko Schlichting in bln.announce.fub.zedat.d
mit <7ahusp$n6f$1@fu-berlin.de> einen Artikel geschrieben, der
das so schön erklärt, daß ich ihn einfach übernehmen möchte:
---- 8< ----
> Ich versteh nicht, warum in meiner Mailbox [...] Emails wie
> die folgende landen. Kann mir das jemand erklären? Meine Adresse
> ist doch gar nicht im Header der Email aufgeführt.
Man unterscheidet bei E-Mail zwischen Envelope und Header. Die
Programme, die die Auslieferung durchführen (*), richten sich
nach der Adresse im Envelope. Dieser wird bei der letzten Zu-
stellung (also dem Anhängen der Mail in Deiner Mailbox) entfernt.
Was Dein Mail-Anzeigeprogramm (**) Dir anzeigt, ist nur der Header.
Er ist zu Deiner Information gedacht, hat aber bei der Auslieferung
keine Rolle gespielt.
Als Vergleich zur normalen Briefpost:
------------------------+-------------------------------------
E-Mail | Briefpost
========================+=====================================
Envelope-Adresse | Adresse auf dem Umschlag
------------------------+-------------------------------------
Header | Briefkopf auf der ersten Seite
------------------------+-------------------------------------
Der Briefträger orientiert sich auch nicht an den Angaben im
Briefkopf, sondern immer nur an den Angaben auf dem Umschlag.
Genau wie bei der klassischen Briefpost sind folgende Angaben
übrigens leicht fälschbar (***):
- Absender im Envelope
- Adressat und Absender im Header
Wer in Mailinglisten eingetragen ist, wird die Unterscheidung von
Envelope und Header schon gesehen haben. Dort ist nämlich in der
Regel im HEADER der Autor der Nachricht im From und die Mailingliste
im To: eingetragen. In Wirklichkeit lief die Mail aber von dem
Mailinglisten-Verteiler an den Mailinglisten-Teilnehmer. Diese
beiden Adressen stehen im Envelope-Teil, der nach der Auslieferung
nicht mehr sichtbar ist. Manche Transport-Systeme tragen diese
Information aber in den Received:-Zeilen im Header ein, so daß man
das dort ggf. nachlesen kann [...].
Wenn eine Mail nicht zugestellt werden kann, wird die Fehlermeldung
übrigens grundsätzlich an die Absender-Information im Envelope (und
nicht etwa an die Adresse im From:-Header) zurückgeschickt. Wer
jetzt an die Einträge bei Mailinglisten denkt, wird sofort erkennen,
warum das so sein muß.
Wenn sich jemand bei der ZEDAT beklagt, daß seine Mail "verloren"
gegangen ist (nicht beim Empfänger angekommen und keine Fehlermeldung
zurückgekommen), dann liegt es in mehr als 90% der Fälle daran, daß
der Absender sein Programm bezüglich der Envelope-Absenderadresse
falsch konfiguriert hat und eine erzeugte Fehlermeldung daher nicht
richtig zurückgeschickt werden konnte. Das hat der Absender nur nie
bemerkt, weil normale Antworten immer den (meist richtig konfigurierten)
From:-Header verwenden. Wer seine Einträge testen möchte, kann eine
Mail an "echo@fu-berlin.de" schicken. Da sollte nach kurzer Zeit eine
Antwort zurück kommen. Wenn nicht, sind die Einträge vermutlich falsch
und sollten korrigiert werden.
[...]
(*) Message Transfer Agent (MTA) - in der ZEDAT heißt das Programm
"smail", ein häufiger Vertreter dieser Art ist auch das Programm
"sendmail".
(**) Mail User Agent (MUA) - dazu gehören pine, mutt, elm, Netscape,
Outlook Express, Eudora, Pegasus, Agent u.v.a.m.
(***) Das Versenden gefälschter Mail von einem FU-Account aus könnte
ggf. zur Sperrung der Nutzerkennung führen. Leicht fälschbar
bedeutet nicht, daß dieses mit geeigneten Zugriffsrechten nicht
nachvollziehbar wäre.
[...]
---- 8< ----
Neben dem erwähnten "Envelope" gibt es noch eine weitere Möglichkeit,
wieso man sich selbst nicht in "To:" oder "Cc:" sehen kann, aber eine
Mail dennoch bekommen hat:
Das Header-Feld "Bcc:" (Blind Carbon Copy).
Aus RFC 2822:
3.6.3. Destination address fields
[...]
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
Deutschsprachige Ausführungen zum Thema "Bcc" (von Matthias Opatz):
* Das Geheimnis der »blinden Durchschläge«
http://www.trollpress.de/bcc/
Frage 5:
========
* Wie liest man einen Mail-Header?
A: Zum Verständnis eines Mail-Headers gibt es eine FAQ von
Thomas Hochstein namens "E-Mail-Header lesen und verstehen",
die regelmäßig in danam (de.admin.net-abuse.mail) gepostet
wird und im WWW unter folgender URL zu finden ist:
* FAQ: E-Mail-Header lesen und verstehen
http://www.th-h.de/faq/headrfaq.html
Aufgrund des mittlerweile sehr beträchtlichen Umfanges der
danam-FAQ wird an dieser Stelle nicht näher auf das Lesen von
Mail-Headern eingegangen, sondern auf die existierende Spezial-
FAQ zu diesem Thema verwiesen.
Frage 6:
========
* Hilfe! Mein Mailserver / Webserver wird als Relay mißbraucht!
Was kann ich tun?
A: Dem Mailserver abgewöhnen, Mail von nicht-lokalen Usern oder
Systemen anzunehmen und weiterzuleiten, die nicht für lokale Benutzer
oder Systeme, für die der Mailserver zuständig ist, bestimmt ist.
Man spricht von "einem Mailserver das Relayen abgewöhnen" oder
"ein offenes Relay schließen".
Nützliche URLs und FAQs zu diesem Thema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allgemeines:
* What is Third-Party Mail Relay?
http://mail-abuse.org/tsi/ar-what.html
* Is my Mailer vulnerable?
http://mail-abuse.org/tsi/ar-test.html
* How can I fix the Problem?
http://mail-abuse.org/tsi/ar-fix.html
* Open Relay Testing
http://www.abuse.net/relay.html
* Open Relay Testing
http://www.paladincorp.com.au/unix/spam/spamlart/
* Open Relay Testing
http://members.iinet.net.au/~remmie/relay/
* Open Relay Testing
http://www.fabel.dk/relay/test/
* Open Relay Testing
http://www.ordb.org/submit/
* Relay Testing Tool (Perl)
http://www.unicom.com/sw/rlytest/
* Relay Testing Tool (Perl)
ftp://ftp.ruhr-uni-bochum.de/local/mail/spamtools/relaytest
* What to do when your Service is stolen by Junk-Mailers
http://www.support.uk.psi.com/help/ubm-help.html
MTA-spezifische Einzel-Links:
Exim:
* HOWTO - Preventing Relaying
http://www.exim.org/howto/relay.html
Sendmail:
* Anti-Spam Provisions in Sendmail 8.8
http://www.sendmail.org/antispam.html
* Allowing controlled SMTP Relaying in Sendmail 8.9
http://www.sendmail.org/tips/relaying.html
* Relaying denied/allowed (in Sendmail 8.8/8.9-8.12)
http://www.sendmail.org/~ca/email/relayingdenied.html
* More Comments about Anti-Relaying
http://www.sendmail.org/~ca/email/norelay.html
* Tips and Hints for Sendmail
http://www.sendmail.org/tips/
* Flexible Mail Relaying Control for Sendmail
http://hexadecimal.uoregon.edu/antirelay/
Postfix:
* Postfix Configuration - UCE Controls
http://www.postfix.org/uce.html
* What Clients to relay Mail for
http://www.postfix.org/basic.html#relaying
Tobit:
* Wie man Tobit relaysicher machen kann
http://www.rince.de/block/
Microsoft Exchange Server 5.5:
* Preventing from Relaying Unsolicited Commercial E-Mail Messages
http://support.microsoft.com/support/kb/articles/Q193/9/22.ASP
Netscape Messaging Server:
* Anti-Relay and RBL Configuration in Netscape Messaging Server
http://appsrv.ttnet.net.tr/netscape/
SMTP after POP:
* Dynamic Relay Authorization Control
http://mail.cc.umanitoba.ca/drac/index.html
* POP before SMTP for Sendmail
http://spam.abuse.net/adminhelp/smPbS.shtml
* SMTP after POP mit Sendmail und Qpopper
http://kuerbis.org/smtpapop/
* POPauthd - Authenticating SMTP Relaying Using POP
http://straylight.primelogic.com/popauthd/
* SMTP after POP - Kontrolliertes Mail Relaying
http://www.koblenz-net.de/~horn/smtp_after_pop/doc/
* Poprelay (Sendmail)
http://poprelay.sourceforge.net/
* smtp-poplock (Qmail)
http://www.davideous.com/smtp-poplock/
* SMTP after POP (Qmail)
http://www.qmail.org/open-smtp3.tar.gz
SMTP AUTH - SMTP Service Extension for Authentication:
SMTP AUTH ist eine SMTP Service Extension [ESMTP] für MTAs, die
es ermöglicht, daß sich ein Client über ein Passwort beim Server
authentifiziert, um den Mailserver dann zum Verschicken von Mail
benutzen zu können. Die Nummer des entsprechenden RFCs ist 2554
("SMTP Service Extension for Authentication").
SMTP AUTH Client Info
* Clients supporting SMTP AUTH
http://members.elysium.pl/brush/smtp-auth/client.html
* List of MUAs that support SASL
http://www.sendmail.org/~ca/email/other/auth-mua.html
SMTP AUTH Server Info
Allgemeines:
* Server Support for SMTP AUTH
http://members.elysium.pl/brush/smtp-auth/server.html
MTA-spezifisch:
Exim:
* Exim Specification - SMTP Authentication
http://www.exim.org/exim-html-3.30/doc/html/spec_35.html
http://www.exim.org/exim-html-4.10/doc/html/spec_32.html
Sendmail:
* SMTP AUTH in Sendmail 8.10-8.12
http://www.sendmail.org/~ca/email/auth.html
Qmail:
* Patch for Qmail that enables it to support SMTP AUTH
http://members.elysium.pl/brush/qmail-smtpd-auth/index.html
* SMTP Authentication for Qmail
http://www.cuni.cz/~vhor/qmail/smtpauth-en.html
Postfix:
* Postfix SMTP Authentication
http://www.thecabal.org/~devin/postfix/smtp-auth.txt
Miscellaneous:
* (Deutsche) Provider und ihre Mail-Systeme
http://home.nexgo.de/whdk/hamster/Smarthost.html
* Authorisationsmöglichkeiten von SMTP-Servern
http://www.philippwendler.de/saslsmtp.html
Neue Dimensionen des Spams oder - "Hilfe, mein Webserver relayed!":
In der jüngeren Vergangenheit treten immer häufiger Fälle auf,
in denen CGI-Scripts wie z.B. FormMail von externen Dritten dazu
mißbraucht werden, grosse Mengen von Spam-Mail durch geeignete
Angabe von Parametern via HTTP-Request zu verschicken.
Weitere Informationen:
* Anti-Spam & Security Fix for FormMail.pl
http://www.mailvalley.com/formmail/
* BugTraq
http://www.securityfocus.com/archive/1/168177
http://www.securityfocus.com/archive/1/59441
* SecurityTracker.com
http://securitytracker.com/alerts/2001/Mar/1001108.html
* nms - Alternative CGI-Scripts
http://nms-cgi.sourceforge.net/
Betreiber von Webservern sollten regelmäßig die Logfiles ihrer
Webserver durchsehen, die Log-Einträge von derart mißbrauchten
CGIs sind zumindest beim Apache sehr auffällig. In den meisten
Fällen treffen zusätzlich zeitnah externe Beschwerden von Spam-
Empfängern ein; die in diesen Beschwerden (hoffentlich) mitge-
schickten Header deuten in den allermeisten Fällen auf einen
lokalen User als Verursacher, der in einem solchen Fall jedoch
auch nur Opfer ist. Der einzige Vorwurf, der dem User zu machen
ist, ist, daß er ein CGI geschrieben oder installiert hat, das
sich von Dritten zum Verschicken von Spam mißbrauchen lässt.
Programmierer und Benutzer von CGIs sollten ihre CGIs gründlich
testen, ob sie "relay-sicher" sind. D.h., daß sie sich nicht von
von Dritten dazu mißbrauchen lassen, Spam - meist sogar unter
den Kennungen des Seiteninhabers! - zu verschicken!
Ebenfalls in die Kategorie oftmals übersehener, von Spammern
ausnutzbarer Lücken fallen fehlkonfigurierte Proxy-Server:
* Open Proxies
http://spamlinks.net/proxy.htm
* Open Proxy Servers: A Growing Source of Spam
http://cc.uoregon.edu/cnews/fall2002/openproxy.html
* Abuse-Proxy Project
http://www.cyberabuse.org/?page=abuse-proxy
* Proxy Scanner
http://www.cyberabuse.org/?page=proxyscanner
Frage 7:
========
* Hilfe! Meine Adresse oder meine Domain wird als Absender in Spam
mißbraucht! Was kann ich tun?
A: Eine der verwerflichsten und verabscheuungswürdigsten Aus-
prägungen von Spam ist der Mißbrauch von existierenden Kennungen
unbeteiligter Leute als vermeintliche Absender von Spam. Dies
kann gezielt und absichtlich geschehen, um jemanden bestimmtes
zu diskreditieren, in den häufigsten Fällen wählen Spammer die
fremden Kennungen jedoch ungerichtet mit dem Ziel, die wahre
Herkunft des Spams zu verschleiern, Beschwerden zu erschweren
resp. auf unbeteiligte Dritte zu lenken.
Wie merke ich, daß meine Kennungen als Absender in Spam miß-
braucht wurden? Einer der untrüglichsten Hinweise sind Bounces;
man erhält - oftmals in grosser Menge - Unzustellbarkeitsmeldungen
über Mail, die man niemals verschickt hat. Ist Mail nicht zustell-
bar, kehren die Unzustellbarkeitsmeldungen (Bounces) zum ange-
gebenen Absender zurück, ein normalerweise gutes und sinnvolles
Feature, um den Absender einer Mail über Probleme zu informieren.
Da Spam grosse Mengen von Bounces erzeugt, da viele der ange-
schriebenen Adressen ungültig sind oder die Empfänger die Annahme
blockieren, erhält das unwissende Opfer von Kennungsmißbrauch
diese Bounces, da seine Kennungen als Absender benutzt wurden.
Ein weiterer Hinweis, daß eigene Kennungen mißbraucht wurden,
sind Hinweise oder Beschwerden z.B. von Spam-Empfängern oder dem
eigenen ISP, der Beschwerden erhalten hat.
Was kann man nun machen, wenn man Opfer eines solchen Mißbrauchs
wurde?
* Informiere Deinen ISP resp. die für Dich zuständigen Administra-
toren umgehend darüber, daß Deine Kennungen mißbraucht wurden
und Du keinen Spam verschickt hast! Füge einen Beispiel-Spam,
einen Header oder einen Bounce bei! Dies verhindert Mißverständ-
nisse und Maßnahmen gegen Deine Accounts.
* Ermittele aus den erhaltenen Bounces soweit es möglich ist den
wahren Absender des Spams; für Hinweise und Anleitungen zur
Analyse siehe Frage 5 dieser FAQ. Beschwere Dich bei den so er-
mittelten Stellen (Betreiber eines offenen Relays, ISP eines zum
Spammen benutzten Dialups etc.).
* Schreibe - am besten in mehreren Sprachen, mindestens aber in
Englisch - einen kurzen erklärenden Text, daß Deine Kennungen
mißbraucht wurden, Du natürlich keinen Spam verschickt hast,
und schicke ihn den Leuten, die sich direkt bei Dir beschwert
haben, stelle den Text vielleicht sogar auf Deine Homepage.
Füge diesem Text die Ergebnisse Deiner Analyse bezüglich des
wirklichen Absenders bei und bitte die Leute, sich bei den zu-
ständigen Stellen zu beschweren.
* Sofern eine Adresse als Absender benutzt wurde, die Du nicht
oder nur sehr selten benutzt, solltest Du darüber hinaus in
Erwägung ziehen, Mail an diese Adresse automatisch löschen zu
lassen. Es sind Fälle bekannt, in denen Tausende von Bounces
zusammenkamen, mehr, als Dein Postfach vielleicht aushalten
und Du durchsehen kannst!
Wie bereits eingangs ausgeführt, ist die Form des Kennungsmißbrauchs
besonders ekelhaft und verabscheuungswürdig. Gefeit dagegen ist nie-
mand, und die Möglichkeiten, sich im Falle eines Falles zur Wehr zu
setzen, sind oftmals eher unbefriedigend. Ein Grund mehr, sich aktiv
dafür einzusetzen, daß in Bezug auf Spam mehr z.B. von Seiten der
Gesetzgebung und Politik getan wird, damit sowohl das Entstehen von
Spam eingedämmt wird als auch die Strafen für Spammer drakonischer
werden.
Englischsprachige Ausführungen zum Thema Kennungsmißbrauch (auch
als "Joe Job" bezeichnet):
* FAQ for news.admin.net-abuse.email
http://www.spamfaq.net/terminology.shtml#joe_job
* 3 simple steps: What to do after a JOE-JOB
http://groups.google.com/groups?selm=3C703AAC.3923EDA5%40tls.msk.ru
* The Story of joes.com
http://www.joes.com/spammed.html
E. Andere Dokumente und Newsgruppen
===================================
Newsgruppen:
* de.admin.net-abuse.announce: Massnahmen gegen Netzmissbrauch (moderiert)
* de.admin.net-abuse.misc: Sonstiger Netzmissbrauch
* de.admin.net-abuse.news: Fehlverhalten im Usenet
* de.comm.abuse: Missbraeuchliche Nutzung von Fax, Telefon, SMS etc.
* de.alt.comp.the-bat: Mailen mit der Fledermaus
* de.comm.provider.mail: Zugangsunabhaengige E-Mail-Dienste
* de.comm.software.forte-agent: News und Mail mit Forte (Free) Agent
* de.comm.software.gnus: Der News- und Mailclient im Emacs
* de.comm.software.outlook-express: Mail und News nach Microsoft-Art
* de.comm.software.mailreader.misc: Mailreader und Hilfsprogramme
* de.comm.software.mailreader.pegasus: Pegasus Mail (PMail/WinPMail)
* de.comm.software.mailserver: Mailtransport und -zustellung
* spamcop.* (Server: news.spamcop.net)
Commands, Reply Codes, RFCs:
* SMTP - Simple Mail Transfer Protocol
http://www.networksorcery.com/enp/protocol/smtp.htm
* IMAP - Internet Message Access Protocol
http://www.networksorcery.com/enp/protocol/imap.htm
* POP - Post Office Protocol
http://www.networksorcery.com/enp/protocol/pop.htm
RFCs (Request for Comments):
* RFC Editor
http://www.rfc-editor.org/
* FTP-Server der FU Berlin
ftp://ftp.fu-berlin.de/doc/rfc/
* AlterNIC - RFC & Draft Index and Search Engine
http://www.alternic.org/
* Mail and News related RFCs and Drafts
http://www.tin.org/docs.html
* The RFC Sourcebook
http://www.networksorcery.com/enp/default.htm
* RFC 0821: Simple Mail Transfer Protocol
J. Postel, Aug-01-1982
Obsoletes: RFC 0788
Obsoleted by: RFC 2821
Status: STANDARD
* RFC 0822: Standard for the format of ARPA Internet text messages
D. Crocker, Aug-13-1982
Obsoletes: RFC 0733
Updated by: RFC 1123, RFC 1138, RFC 1148, RFC 1327, RFC 2156
Obsoleted by: RFC 2822
Status: STANDARD
* RFC 1036: Standard for interchange of USENET messages
M.R. Horton, R. Adams, Dec-01-1987
Obsoletes: RFC 0850
Status: UNKNOWN
* RFC 1082: Post Office Protocol: Version 3: Extended service offerings
M.T. Rose, Nov-01-1988
Status: UNKNOWN
* RFC 1123: Requirements for Internet Hosts - Application and Support
R. Braden, Ed., October 1989
Updates: RFC 0822
Updated by: RFC 1349, RFC 2181
Status: STANDARD
* RFC 1731: IMAP4 Authentication Mechanisms
J. Myers, December 1994
Status: PROPOSED STANDARD
* RFC 1734: POP3 AUTHentication command
J. Myers, December 1994
Status: PROPOSED STANDARD
* RFC 1939: Post Office Protocol - Version 3
J. Myers, M. Rose, May 1996
Obsoletes: RFC 1725
Updated by: RFC 1957, RFC 2449
Status: STANDARD
* RFC 1957: Some Observations on Implementations of the Post
Office Protocol (POP3)
R. Nelson, June 1996
Updates: RFC 1939
Status: INFORMATIONAL
* RFC 2076: Common Internet Message Headers
J. Palme, February 1997
Status: INFORMATIONAL
* RFC 2142: Mailbox Names for Common Services, Roles and Functions
D. Crocker, May 1997
Status: PROPOSED STANDARD
* RFC 2181: Clarifications to the DNS Specification
R. Elz, R. Bush, July 1997
Updates: RFC 1034, RFC 1035, RFC 1123
Updated by: RFC 2535
Status: PROPOSED STANDARD
* RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response
J. Klensin, R. Catoe, P. Krumviede, September 1997
Obsoletes: RFC 2095
Status: PROPOSED STANDARD
* RFC 2298: An Extensible Message Format for Message Disposition
Notifications
R. Fajman, March 1998
Status: PROPOSED STANDARD
* RFC 2449: POP3 Extension Mechanism
R. Gellens, C. Newman, L. Lundblade, November 1998
Updates: RFC 1939
Status: PROPOSED STANDARD
* RFC 2476: Message Submission
R. Gellens, J. Klensin, December 1998
Status: PROPOSED STANDARD
* RFC 2505: Anti-Spam Recommendations for SMTP MTAs
G. Lindberg, February 1999
Status: BEST CURRENT PRACTICE
* RFC 2554: SMTP Service Extension for Authentication
J. Myers, March 1999
Status: PROPOSED STANDARD
* RFC 2595: Using TLS with IMAP, POP3 and ACAP
C. Newman, June 1999
Status: PROPOSED STANDARD
* RFC 2635: DON'T SPEW A Set of Guidelines for Mass Unsolicited
Mailings and Postings (spam*)
S. Hambridge, A. Lunde, June 1999
Status: INFORMATIONAL
* RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
R. Gellens, August 1999
Status: PROPOSED STANDARD
* RFC 2683: IMAP4 Implementation Recommendations
B. Leiba, September 1999
Status: INFORMATIONAL
* RFC 2821: Simple Mail Transfer Protocol
J. Klensin, Ed., April 2001
Obsoletes: RFC 0821, RFC 0974, RFC 1869
Status: PROPOSED STANDARD
* RFC 2822: Internet Message Format
P. Resnick, Ed., April 2001
Obsoletes: RFC 0822
Status: PROPOSED STANDARD
* RFC 2852: Deliver By SMTP Service Extension
D. Newman, June 2000
Updates: RFC 1894
Status: PROPOSED STANDARD
* RFC 2920: SMTP Service Extension for Command Pipelining
N. Freed, September 2000
Obsoletes: RFC 2197
Status: STANDARD
* RFC 2971: IMAP4 ID extension
T. Showalter, October 2000
Status: PROPOSED STANDARD
* RFC 2980: Common NNTP Extensions
S. Barber, October 2000
Status: INFORMATIONAL
* RFC 3028: Sieve: A Mail Filtering Language
T. Showalter, January 2001
Status: PROPOSED STANDARD
* RFC 3030: SMTP Service Extensions for Transmission of Large and
Binary MIME Messages
G. Vaudreuil, December 2000
Obsoletes: RFC 1830
Status: PROPOSED STANDARD
* RFC 3098: How to Advertise Responsibly Using E-Mail and Newsgroups
or - How NOT to $$$$$ MAKE ENEMIES FAST! $$$$$
E. Gavin, April 2001
Status: INFORMATIONAL
* RFC 3206: The SYS and AUTH POP Response Codes
R. Gellens, February 2002
Status: PROPOSED STANDARD
* RFC 3207: SMTP Service Extension for Secure SMTP over Transport
Layer Security
P. Hoffman, February 2002
Obsoletes: RFC 2487
Status: PROPOSED STANDARD
* RFC 3297: Content Negotiation for Messaging Services based on Email
G. Klyne, R. Iwazaki, D. Crocker, July 2002
Status: PROPOSED STANDARD
* RFC 3348: The Internet Message Action Protocol (IMAP4) Child
Mailbox Extension
M. Gahrns, R. Cheng, July 2002
Status: INFORMATIONAL
* RFC 3431: Sieve Extension: Relational Tests
W. Segmuller, December 2002
Status: PROPOSED STANDARD
* RFC 3458: Message Context for Internet Mail
E. Burger, E. Candell, C. Eliot, G. Klyne, January 2003
Status: PROPOSED STANDARD
* RFC 3462: The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages
G. Vaudreuil, January 2003
Obsoletes: RFC 1892
Status: DRAFT STANDARD
* RFC 3463: Enhanced Mail System Status Code
G. Vaudreuil, January 2003
Obsoletes: RFC 1893
Status: DRAFT STANDARD
* RFC 3501: Internet Message Access Protocol - Version 4rev1
M. Crispin, March 2003
Obsoletes: RFC 2060
Status: PROPOSED STANDARD
* RFC 3502: Internet Message Access Protocol (IMAP) - Multiappend
Extension
M. Crispin, March 2003
Status: PROPOSED STANDARD
* RFC 3503: Message Disposition Notification (MDN) profile for
Internet Message Access Protocol (IMAP)
A. Melnikov, March 2003
Status: PROPOSED STANDARD
* RFC 3516: IMAP4 Binary Content Extension
L. Nerenberg, April 2003
Status: PROPOSED STANDARD
* DRUMS - Detailed Revision/Update of Message Standards: "The goal
of this working group is to develop and review revised versions
of RFC 821 and RFC 822, incorporating the revisions in RFC 974,
RFC 1123, and RFC 1651", siehe
http://www.ietf.org/html.charters/drums-charter.html
* News Article Format and Transmission - Internet draft to be;
auch "Son Of RFC 1036" genannt. 1994 von Henry Spencer, siehe
ftp://ftp.zoo.toronto.edu/pub/news.txt.Z
* UseFor - Usenet Article Standard Update: "The Goal of this working
group is to publish a standards-track successor to RFC 1036 that
with particular attention to backward compatibility, formalizes
best current practice and best proposed practice. The Group shall
also aid and/or oversee the production of other Usenet related
Internet Drafts and Standards"; auch "Grandson Of RFC 1036" ge-
genannt. 1997 - ????, siehe
http://www.landfield.com/usefor/
Paperware
=========
* "Stopping Spam - Stamping Out Unwanted Email & News Postings"
Alan Schwartz & Simson Garfinkel
October 1998: First Edition
"Stopping Spam" is a book about unwanted email messages and
inappropriate news articles - what they are, who is sending
them, how to stop them, and even how to outlaw them. It's
a book about what has come to be called "Internet Spam".
O'Reilly Verlag
ISBN: 1-56592-388-X
US $19.95
(etwa 190 Seiten, "normales" O'Reilly-Buch-Format)
Dieses Buch bei Amazon anschauen (derzeit jedoch nicht verfügbar):
http://www.amazon.de/exec/obidos/ASIN/156592388X/
* "Stoppt Spam - kurz & gut"
Alan Schwartz & Simson Garfinkel [Übersetzung: Eva Wolfram]
1. Auflage - Köln; 1999
Basiert auf Teilen des O'Reilly-Titels "Stopping Spam", die im
Hinblick auf den deutschen Markt überarbeitet und um Informationen
zur deutschen Rechtslage sowie um entsprechende aktuelle Web-
Ressourcen zum Thema Spam ergänzt wurden.
O'Reillys Taschenbibliothek
ISBN: 3-89721-221-8
DEM 12,80 / ATS 93,-
(etwa 90 Seiten, Pocket-Reference-Format)
Dieses Buch bei Amazon anschauen (derzeit jedoch nicht verfügbar):
http://www.amazon.de/exec/obidos/ASIN/3897212218/
Nicht zum Schluß: Keep smiling!
===============================
* Dan Garcia's Spam Page
http://www.cs.berkeley.edu/~ddgarcia/spam.html
* Spam is not the worst of it (bitter!)
http://unquietmind.com/email.html (Original)
http://www.dominik-boecker.de/email/index.html (dt. Übersetzung)
* You might be an anti-spam kook if ...
http://www.rhyolite.com/anti-spam/you-might-be.html
Credits
=======
Mein Dank geht an Jan Krüger (für die "alte" FAQ, die mir Stütze
und Struktur für meinen Text war) sowie an alle Leute, die diese
FAQ durch Korrekturlesen, Anregungen und Kritik mit erschaffen
und mit weiterentwickelt haben.
Anmerkungen
===========
Kritik, Ergänzungen, Verbesserungen, Hinweise auf Fehler, Ideen und
vielleicht auch Lob sind willkommen; falls in den News gepostet wird,
wird um eine Courtesy Copy (Mail-Kopie) gebeten.
Autor: Bettina Fink <laura@hydrophil.de>