Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.telebyte.nl!news.newsland.it!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.hanau.net!wuff.zikzak.de!krell!abraxas.zikzak.de!not-for-mail

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.telebyte.nl!news.newsland.it!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.hanau.net!wuff.zikzak.de!krell!abraxas.zikzak.de!not-for-mail
From: Bettina Fink <[email protected]>
Newsgroups: de.admin.net-abuse.mail,de.answers,news.answers
Subject: <2004-05-06> FAQ, Abkuerzungen: de.admin.net-abuse.mail
Supersedes: <[email protected]>
Followup-To: de.admin.net-abuse.mail
Date: 6 May 2004 14:16:12 GMT
Organization: Stop spam!
Lines: 2299
Approved: [email protected]
Message-ID: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Summary: This posting describes frequently asked questions (and their answers) and typical problems regarding mail abuse. It's in German, like the newsgroup.
Xref: senator-bedfellow.mit.edu de.answers:10451 news.answers:270968

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 <[email protected]>

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):
[email protected]
[email protected]
[email protected]

* Andere Telekom-Domains und -IPs, Reseller-Dialups etc.:
[email protected]

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: <[email protected]>

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 <[email protected]> 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 "[email protected]" 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 <[email protected]>