Subject: <2003-02-03> FAQ, Abkuerzungen: de.admin.net-abuse.mail
From: Bettina Fink <[email-masked]>
Date: 3 Mar 2003 22:15:18 GMT
Newsgroups: de.admin.net-abuse.mail,de.answers,news.answers

Archive-name: de-net-abuse/mail-faq
Posting-Frequency: 14 days
Last-modified: 2003-02-03
URL: http://home.snafu.de/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
====================================

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://home.snafu.de/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.zigenhorn.de/mlm.htm  (Christian Zigenhorn)
        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://home.t-online.de/home/jwiedelmann/Straftaten/Kapitalanlage/Nigeria/nigeria.html

      * Kapitalanlagebetrug
        http://home.t-online.de/home/jwiedelmann/Straftaten/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

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/

          * The SpamDunk Project
            http://www3.sympatico.ca/walter.dnes/email/spamdunk/index.html

          * 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/

          * 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

          * rblchk e-mail filter
            http://alcor.concordia.ca/nonalcor/email/rblchk/

   * 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!

   * 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

   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://faq.gmx.de/faq/3.html

   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

   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.00/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 3.15 for Sendmail 8.9
     http://www.unix-ag.uni-hannover.de/soft/check_local/

   * Extended Spam Filter: check_local 4.4 for Sendmail 8.11
     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/

   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

   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
     http://www.cyberkit.net/

   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/

   * IP Network Index
     http://www.ipindex.net/

   * 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

   * 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/

   * Proxy Checker
     http://cache.jp.apan.net/proxy-checker/

   * SpamArchive.org
     http://spamarchive.org/

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

   * t-ipconnect.de (Reseller-Dialups):
     [email-masked]

   * Andere Telekom-Domains und -IPs:
     [email-masked]

   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:

   | 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-masked]>

   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:

   * Akzeptables E-Mail-Marketing
     http://www.werbeformen.de/werbeformen/aktuell/bb.shtml

   * 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-masked]> 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-masked]" 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 Configuration Control
     http://www.sendmail.org/m4/anti-spam.html

   * 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

   * 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

   * SMTP AUTH Clients
     http://www3.innosoft.com/~chris/smtpauth_client.html

   * 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

   * Authenticated Mail Submission
     http://www3.innosoft.com/~chris/smtpauth.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.00/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

   * qmail-smtpd.c
     http://www.nimh.org/hacks/qmail-smtpd.c

   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://www.geocities.com/spamresources/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 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 1830: SMTP Service Extensions for Transmission of
                 Large and Binary MIME Messages
       G. Vaudreuil, August 1995
       Obsoleted by: RFC 3030
       Status: EXPERIMENTAL

     * RFC 1854: SMTP Service Extension for Command Pipelining
       N. Freed, October 1995
       Obsoleted by: RFC 2197
       Status: PROPOSED STANDARD

     * RFC 1893: Enhanced Mail System Status Codes
       G. Vaudreuil, January 1996
       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 2060: Internet Message Access Protocol - Version 4rev1
       M. Crispin, December 1996
       Obsoletes: RFC 1730
       Status: PROPOSED STANDARD

     * RFC 2076: Common Internet Message Headers
       J. Palme, February 1997
       Status: INFORMATIONAL

     * RFC 2095: IMAP/POP AUTHorize Extension for Simple Challenge/Response
       J. Klensin, R. Catoe, P. Krumviede, January 1997
       Obsoleted by: RFC 2195
       Status: PROPOSED STANDARD

     * RFC 2142: Mailbox Names for Common Services, Roles and Functions
       D. Crocker, May 1997
       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 2197: SMTP Service Extension for Command Pipelining
       N. Freed, September 1997
       Obsoletes: RFC 1854
       Obsoleted by: RFC 2920
       Status: DRAFT 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 2487: SMTP Service Extension for Secure SMTP over TLS
       P. Hoffman, January 1999
       Obsoleted by: RFC 3207
       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

     * 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

     * RCN's Abuse Staff
       http://users.erols.com/abuse/admins.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)

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-masked]>