Spam-Trap

From C3D2
Jump to: navigation, search

Contents

Spam Trap

Ziel

Das Ziel ist einen minimalen (E)SMTP Server zu betreiben, der soviel Spam sammelt wie möglich. Praktisch wäre, wenn er eine komplette Domain (.*@foobar.de) bedient.

Interessierte Leute

  • astro
  • blitz
  • beanie
  • leon betreibt schon eine spamtrap auf zaphod.leonweber.de, die bisher nur die bayes-db fuettert. Die Mails koennten wir, wenn gewuenscht, benutzen, d.h. weiteraliasen. Koennte man dann allerdings mit dem SMTP-Dialog nix anfangen, weil der dann halt von meinem Postfix kommt.
  • ...

Potentielle Server-Implementationen

Allgemeine Fähigkeiten einer Implementation

  • der eigentliche SMTP-Server

Binary Mail Stream Protocol (BMSP) via TCP

Da mehrere Serverimplementationen nicht einen Port 25 gleichzeitig bedienen können, muß der am Port 25 die Mails den anderen zur Verfügung stellen. Am besten, er hat nen offenen Serverport und schiebt die Messages in folgendem Format an die dort verbundenen Clients (die anderen Serverimplementationen) raus.

+-+----+-----+--------+--------+----+------+----+------+----+----+------+----+-------------------------------+
|1|  L | IP  | Start  | End    | LH | H... | LF | F... | LLT| LT | T... | DL | D................ ... ... ... |
+-+----+-----+--------+--------+----+------+----+------+----+----+------+----+-------------------------------+
                                                          *__(_________)
1
Version 1, 8 Bit
L
Länge des folgenden Blocks, 32 Bit, unsigned, network byte order
IP
Sender-IP, 32 Bit, network byte order
Start
Startzeitpunkt der SMTP-Session in Millisekunden seit 1970, 64 Bit, unsigned, network byte order
End
Endzeitpunkt der SMTP-Session in Millisekunden seit 1970, 64 Bit, unsigned, network byte order
L*
Länge des folgenden Felds, 32 Bit, unsigned, network byte order
H
HELO/EHLO-Host
F
From:
LLT
Anzahl der folgenden LT- & T-Felder, 16 Bit, unsigned, network byte order
T
To:
D
Data

Datenhaltung

Da Informationen aus dem SMTP-Dialog auch interessant sind, sind bestehende Maildatenformate (MBOX, Maildir etc) wohl nicht dazu geeignet den gesammelten Müll adäquat zu archivieren. Folgende Möglichkeiten fallen mir spontan ein:

Metadaten

Wenn man nicht seinen Filter trainieren möchte, sind vorrangig folgende Daten interessant:

  • Sender-IP
  • HELO/EHLO-Host
  • From:
  • To:
  • Start- und Endzeitpunkt der SMTP Session
  • Body-Größe in Bytes (neu)

Den kompletten SMTP-Dialog plus Verbindungsinformationen archivieren (vorratsdatenspeichern)

Das hätte den Vorteil, daß man im Nachhinein jede denkbare Auswertung vornehmen kann. Praktisch sollte man sich dabei aber Gedanken machen, wie man das effizient indiziert. Ein Ordner mit ein paar Zehntausend Textdateien bringt es da wohl eher nicht.

Standard-Maildir (oder MBOX) plus Metadaten

...

Was kann man mit dem gesammelten Spam tun?

Eigene DNSBL

...

Tolle Statistiken

  • Bunte Graphen, die interessante Kriterien zeigen

Public API

Jeder sollte darauf zugreifen können. Nur wie? XML-RPC?

  • als ATOM-Feed per HTTP ausliefern

Effektivität anderer Spamfilter testen

Man könnte überprüfen, wie genau Spamhaus&Co, SpamAssassin und andere Spamgegenmaßnahmen den gesammelten Spam erkennen.


Infrastruktur

Wir haben den MX für badpit.c3d2.de auf blackhole zeigend. Von dort kann Port 25 weitergeleitet werden. (NAT oder socat)

Anlocken

Personal tools
Namespaces

Variants
Actions
Navigation
Tools