[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alternative Mail-Systeme (was: AW: Spamhaus PBL)



On Sun, 21 Jan 2007, Peter J. Holzer wrote:

> Skalierbarkeit. Ich glaube nicht, dass ein System, bei dem jeder eine
> globale Sicht des gesamten Systems hat, auf 10^8 Domains skaliert. Das
> würde schon allein an den ständigen Updates ersticken.

Diskussionswürdig. Aggregation existiert (und lässt sich im ggst. Fall
im Gegensatz zu L3-Information auch leicht einsetzen). Ich bin mir über
die "update"-rate nicht ganz im klaren; aber da das alles statisch 
konfiguriert ist vermute ich mal, dass die eher gering ist (ausser der
MX bewegt sich "weit"). Kleinere Verschiebungen gehen mit ziemlicher
sicherheit unter; der Best-Path wird sich ab einem bestimmten Hop
eher nicht mehr ändern.
 
> Es ist auch überhaupt nicht notwendig. Der typische Knoten wird nur
> Mails an ein paar hundert Domains schicken und braucht daher nur
> Routing-Informationen für diese paar hundert Domains. Bisher unbekannte
> Domains kann man bei den Nachbarn erfragen. Ich stelle mir (vielleicht
> etwas naiv) vor, dass ein Flood-Fill-Verfahren für Suchrequests

Das ganze hier klingt nach dem standard-P2P ansatz und die Probleme hier
sind bekannt. Das "rauschen" der Suchen ist hoch; Und spätere Erfindungen
wie "Supernodes" sind auch eher ein Heftpflaster als denn ein echter Fix.

> brauchbar funktionieren sollte: Die Suche nach einigermaßen bekannten
> Domains terminiert ziemlich schnell, weil irgendwer in der Nachbarschaft
> die Domain schon kennt. Die Suche nach bisher unbekannten Domains füllt
> schlimmstenfalls das gesamte Netz aus, aber das sollte sich für legitime
> Domains in Grenzen halten und wenn wer versucht, das Netz lahmzulegen,
> indem er einfach wahllos nach Domains sucht, werden ihm seine Peers auf
> die Finger klopfen (z.B. durch ein Rate-Limit für Suchrequests).

Ungut, das alles. Geh einfach mal davon aus, dass hier nicht einer mit
einem bestimmten Rechner das versucht, sondern ein Bot-Netz hochzieht
das dann ... *PENG*.

> 
> > Im Prinzip dynamische UUCP-Map(s), ein typischer Standard-Endpoint
> > braucht hier eine default-route.
> 
> Das ist ein interessanter Spezialfall. Wenn ein Knoten nur einen
> Nachbarn hat (oder weiß, dass alle bis auf einen "downstream" sind), ist
> es möglich, alles, was man nicht kennt, an diesen Nachbarn zu schicken.

Dieser "nette Spezialfall" wird die meisten Mailserver betreffen (nicht
Mails, sondern die Mailserver).

> Es löst allerdings das generelle Problem nicht, denn ...
> 
> > Oder kommt mit sehr wenigen "peerings" aus.
> 
> schon in diesem Fall braucht er die gesamte Routingtabelle, um zu
> wissen, an welche Domain er über welchen Nachbarn schicken muss. Und
> gerade im Hinblick auf Deinen nächsten Punkt

Nein, musst du nicht. Genauso wie du bei BGP-Multihoming nicht die 
ganze Table brauchst. Du kannst entweder nur 2 Defaults nach aussen 
fahren, oder halt den Table bis zu einer bestimmten Tiefe importieren
(max. HOP-PATH-LEN 3, zum Beispiel).
Oder sonst irgendwie Filtern wenn du lustig bist. Alles was du bei
lookups dann halt nicht importiert hast => default next-hop(s).

> > Ausgetauscht werden statt prefixen domains (resp. MXe). funktioniert
> > mit einem leicht abgewandelten BGP sicher. Der echte Reiz an sowas
> > ist - dass es "richtig" angesetzt auch unglaubliche anonymität bieten
> > kann. Vor allem in Hinsicht auf "Vorratsdatenspeicherung". 
> 
> halte ich es für erstrebenswert, dass jeder mehrere Nachbarn hat und
> nicht die große Masse nur einen Nachbarn (einen großen Mail-Provider),
> an dem man dann einfach den Traffic vieler Leute abfangen kann.

Wie schon geschrieben, das ist kein Problem - das kriegst du bei dem
Protokoll, das ich oben anskizziert habe quasi geschenkt mit. Insbesonders
ist das Setup eines typsichen Endpoints trivial. Der Forwarding-Prozess
bedient nach best-path, bei gleich guten paths im loadbalancing-verfahren
(abwechselnd, z.B). Das ganze ist store-and-forward, die batches lassen
sich verschärft verschluesseln, Encapsulations u.dgl. kriegt man Abfall
mit.
Komplett private pfadnetze lassen sich leicht aufsetzen (funktionieren
gleich wie das öffentliche Pfadnetz) - gateways zwischen privaten/privaten
und privaten/öffentlichen pfadnetzen sind ebenfalls trivial. Die technik
dahinter (routingprotokolle, UUCP) sind altbekannt und vor allem: 
verfügbar (im Sinne von running Code). Gateways/Schnittstellen zum 
"normalen" SMTP existieren (seit Jahrzehnten). Man braucht ausserdem 
keine "zentrale Infrastruktur", keine "Hauptserver". Und ist von jeder
Notwendigkeit einer echtzeit-kommunikation entkoppelt (gut, wenn ich
mail loswerden will, sollte ich verbindung zu mindesten einem Peer 
haben).
Policy-enforcement geht indem peers, über die Müll reinkommt a) ermahnt
und b) abklemmt. Das bringt folgenden Vorteil: Die Nase ist (da mehrere
neighbourse) nicht gleich "offline", rutscht aber über den Druck immer
weiter an den "Rand", wird also solange mit schlechteren laufzeiten
bestraft, bis es dem verbleibenden Peer(s) dann auch irgendwann reicht
(weil sie den ganzen Dreck durchschleusen müssen). Die Kosten von Spam
werden also in Richtung "verursacher" geschoben.

Im Prinzip sehe ich 2 Dinge als ToDo an:

* Das routingprokoll spezifizieren und (ab)schreiben.

* den uucico aufbohren (auf einen innfeed-ähnlichen Betriebsmodus).

Der rest "existiert".