|
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: