Spam

Gegenmaßnahmen

Seit Ende Januar 2003 haben wir im Rechenzentrum auf dem Rechner, auf dem alle Mails von außerhalb landen, zusätzlich zum Virenscanner eine Spam-Erkennungssoftware (Spam-Assassin) eingerichtet.

Die positiv geprüften Regeln werden in zusätzlich eingefügten Header-Zeilen aufgelistet, so daß der einzelne Benutzer bei Lust und/oder Bedarf nachvollziehen kann, wieso eine bestimmte Mail, die er für Spam hält, nicht als solche erkannt wurde, oder wieso eine andere fälschlicherweise als Spam bewertet wurde. Die zugehörigen Werte werden aufsummiert und sowohl als Zahl als auch als Kodierung zur textuellen Erkennung im Header aufgeführt.

Außer dem Einfügen dieser Header-Zeilen findet auf diesem Rechner keine weitere Markierung statt.

Erst auf dem POP3/IMAP-Server des Rechenzentrums wird vor dem Ablegen in der Mailbox nach einer bestimmten Header-Zeile gesucht und ggf. der Text /SPAM!/ dem Subject (Betreff) vorangestellt.

Die entsprechende Konfiguration in der globalen Datei /etc/procmailrc lautet:

# Rewrite Subject Line, if SpamLevel is high enough.
:0fw
* < 256000
* ^X-Spam-Level: \*\*\*\*\*
| sed '1,/^$/s@^Subject:@Subject: /SPAM!/@'

Bei bestimmten Mails -- die, die über die bugtraq-Mailingliste kommen -- ist wegen des Inhalt eine erhöhte Wahrscheinlichkeit gegeben, daß sie fälschlicherweise als Spam klassifiziert werden. Deshalb habe ich mir einen Eintrag für die lokale -- im Heimatkatalog -- Datei .procmailrc fertiggemacht:

# Rewrite Subject Line, if it's bugtraq mail
:0fw
* < 256000
* ^X-Spam-Level: \*\*\*\*\*
* ^TO bugtraq
| sed '1,/^$/s@^Subject: /SPAM!/@Subject:@'

Oder für jemanden, der die ganzen zusätzlichen Header-Zeilen loswerden will:

# X-Spam-?? Header-Zeilen entfernen:    "[ 	]" ist jeweils "[<blank><tab>]"
:0 f
* < 256000
| sed -e '1,/^$/{; /^X-Spam-/d; /^[ 	][ 	]*SPAM: /d; }'

Löschen von Spam

Nachdem nun zum 137. Mal die Frage auftauchte:

Kann das Rechenzentrum die Spam nicht gleich auf dem Server löschen?

Einfache Antwort: Nein, das ist verboten.

Die ausführliche Antwort ändert daran auch nicht viel. Früher gab es im Grundgesetz einen Artikel, der im umgangssprachlichen Gebrauch als Postgeheimnis bezeichnet wurde. Ob es den noch gibt oder ob oder inwieweit er vom "neuen" TKDG (Telekommunikationsdienstegesetz) abgelöst wurde, mögen bitte die Damen und Herren Juristen unter sich ausmachen.
Für mich persönlich habe ich mir folgende Vorgehensweise ausgewählt: Mails, die beim Mailer der Uni ankommen (also nicht als fehlerhaft erst gar nicht angenommen werden), werden auch nach Möglichkeit zugestellt.
Punkt, Ende der Diskussion!

Wer nicht damit einverstanden ist, wird sich wohl an einen meiner Vorgesetzten (Rechenzentrumsleiter, Chief Information Officer, Präsident, ...) wenden und dafür sorgen müssen, daß mir selbiger -- am liebsten schriftlich -- mit den Worten: "Dienstanweisung: ..." nähertritt. (Dann hat er nämlich den Schwarzen Peter.)

Das war der Teil, der sich auf das kollektive Löschen von vermeintlich erkannter Spam bezieht.

neue Regeln zur Erkennung von Spam

Eine andere Frage, die ebenfalls immer wieder auftaucht:

Ich habe hier Spams, die nicht als solche erkannt wurden. Wo kann ich die hinschicken?

Das Regelwerk der von uns verwendeten Spam-Erkennungssoftware (Spam-Assassin) ist recht komplex. Zusätzliche Regeln und/oder Änderungen bei Gewichtungen sind ohne genaue Kenntnis der Verflechtungen des Regelwerks m. E. bedenklich. Deshalb ist momentan keine Adresse zum Abliefern derartiger Mails vorgesehen.

Etwas anders sieht es aus, wenn die Bayes-Funktionalität des Spam-Assassins in Betrieb genommen würde. Da werden dem Programm "gute" und "schlechte" Mails vorgesetzt. Darüber werden -- vereinfacht gesprochen -- Wort-Statistiken aufgebaut. Aus der Häufigkeit und der Kombination der in einer eingehenden Mail vorhandenen Wörter wird entschieden, ob diese Mail als Spam klassifiziert wird oder nicht. Hier wäre es sinnvoll dem Programm mit falsch bzw. nicht erkannter Spam nachträglich näherzutreten. Aber die Methodik mit den Bayes-Filtern ist m. E. nur sinnvoll, wenn der Spam-Filter auf Benutzer-Basis läuft.

Zwei extreme Beispiele:

• Vermutlich spricht nur eine Minderheit der Mitglieder in Uni und FH -- sagen wir z. B. -- polnisch. Also wird eine große Mehrheit Mails mit polnischer Sprache als Inhalt als Spam an den Spam-Assassin verfüttern. Selbiger lernt also, daß polnische Worte stark auf Spam hindeuten und diese Mails entsprechend zu markieren sind. Was andererseits die polnischen Studenten und Gastwissenschaftler traurig machen wird, weil fast alle Mails von zu Hause angeblich Spam seien ...
  (Das gilt natürlich für jede Sprache, die hierzulande keine weite Verbreitung hat.)
• Ein Mitglied von Uni oder FH hat sich die Mühe gemacht eine größere Menge von Spam anzusammeln und will diese nun zu Lernzwecken an den Spam-Assassin verfüttern. Unterstellen wir ihm keine Absicht, sondern wirklich aus Versehen liefert er die Spams als "gute Mails" ab. Damit verschlechtert sich dann die Qualität der Spam-Erkennung. Und zwar für alle!!
  (Im umgekehrten Fall -- "gute Mails" als Spam lernen zu lassen -- ist es noch schlimmer: dann werden in Zukunft zu viele "gute Mails" als Spam klassifiziert.)

In beiden Fällen ist das Ergebnis deutlich weniger zufriedenstellend, als wenn jeder "nur" seinen eigenen Spam-Filter in dieser Art trainieren würde.

Wahrscheinlich wird es in absehbarer Zukunft darauf hinauslaufen, daß das Rechenzentrum einen Spam-Filter mit allgemeinen Regeln zur Verfügung stellt, daß aber darauf aufbauend jeder Nutzer selber für sich eine gewisse Menge Fein-Tuning vornehmen muß. Nur so werden wir akzeptable Spam-Erkennung realisieren können. Momentan scheitert das an der Leistungsfähigkeit des POP3-/IMAP-Servers. Und bevor wir diesen Service über mehrere Rechner verteilen können, sind noch grundlegende Umstellungen (Austausch) von Software notwendig. Diese sind in Vorbereitung ...

Die auf diesen Seiten zum Ausdruck gebrachten Meinungen sind die meinigen, nicht notwendigerweise die der Universität Osnabrück. (Es sei denn, sie würden zufällig übereinstimmen oder wären entsprechend gekennzeichnet.)

Zum Thema "Links":

Bei "Links" handelt es sich stets um "lebende" (dynamische) Verweisungen. Gernot Skalla hat bei der erstmaligen Verknüpfung zwar den fremden Inhalt daraufhin überprüft, ob durch ihn eine mögliche zivilrechtliche oder strafrechtliche Verantwortlichkeit ausgelöst wird. Er überprüft aber die Inhalte, auf die er in seinem Angebot verweist, nicht ständig auf Veränderungen, die eine Verantwortlichkeit neu begründen könnten. Wenn er feststellt oder von anderen darauf hingewiesen wird, daß ein konkretes Angebot, zu dem er einen Link bereitgestellt hat, eine zivil- oder strafrechtliche Verantwortlichkeit auslöst, wird er den Verweis auf dieses Angebot aufheben.