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