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

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



[Falls das Folgende etwas wirr wirkt, dann liegt das daran, dass ich mir
das Konzept wirklich nicht bis zur Prototypenreife durchüberlegt habe.
Soweit ich mich erinnern kann, habe ich nur vor ca. einem Jahr mal mit
dem Clemens bei ein paar Bier darüber diskutiert - möglicherweise habe
habe ich auch anderswo Andeutungen gemacht, aber Draft-RFC gibt es
bislang keinen]

On 2007-01-21 13:11:32 +0100, Martin Hotze wrote:
> Zitat "Peter J. Holzer" <hjp-vibe@hjp.at>:
> >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

Hier sollte ich wohl einfügen, dass "Domain" da nur deshalb steht, weil
die Diskussion diesen Weg genommen hat. Würde ich so ein System
implementieren, wäre es vollkommen flach, und jeder Teilnehmer wäre
durch eine bedeutungslose Adresse (bspw. den Fingerprint eines Public
Keys) identifiziert. Ich schreibe daher im folgenden nur mehr von
"Adressen" und damit sind weder Mail-Adressen der Form <user@domain>
noch Domains noch IP-Adressen gemeint, sondern nur irgendwas
Eindeutiges.


> und die Mails wandern dann durch all diese Mailsysteme (samt deren  
> Limitierungen)?

Kommt darauf an, wen Du mit "all diese Mailsysteme" meinst.

Eine Nachricht geht durch eine Kette von Knoten zwischen Senderknoten
und Empfängerknoten. Entweder könnte jeder Knoten den jeweils nächsten
Hop suchen oder der Senderknoten könnte die Route (oder zumindest
einzelne Punkte davon) festlegen. Ich präferiere letzteres, weil es
erlaubt, dass keiner der Zwischenknoten das endgültige Ziel kennt. Jeder
kennt nur den nächsten Hop und hat keine Ahnung, ob das der Empfänger
oder nur eine weitere Zwischenstation ist. I.A. ist die Länge der Kette
größer als ein Hop, weil man nicht mit allen Leuten, denen man eine
Nachricht schicken will, ein Peering-Abkommen hat. Das gibt eine gewisse
Mindest-Länge vor, aber man kann die Kette auch bewusst verlängern, um
Traffic-Analyse zu erschweren.

Ein Suchrequest geht zunächst mal an alle Nachbarn. Wenn ein Knoten
einen Suchrequest bekommt, kann er ihn entweder aus seinem Cache
beantworten, oder er sendet ihn an alle seine Nachbarn weiter, wenn er
das nicht kürzlich schon getan hat (oder andere Policy-Gründe dagegen
sprechen). Wenn er eine Antwort auf einen Suchrequest bekommt, fügt er
sie in den Cache ein und schaut, ob er noch einen offenen Request hat -
wenn ja, beantwortet er ihn.

> Wie verhindere ich dann dass sich eine Regierung eines  grossen
> Knotens bemächtigt?

Gar nicht. Sie fängt nur relativ wenig damit an. Alles was sie sieht,
sind verschlüsselte Nachrichten, die an einen der Nachbarn
weitergeleitet werden. (So wie ich mir das vorstelle, sehen sie die
Absender (weil ich gerne Absender erkennen möchte und das für den Aufbau
des Caches praktisch ist), aber das das kann ein bedeutungsloses und
beliebig herstellbares Pseudonym sein.

Außerdem sehen sie die Suchrequests und -Replies. Aber wenn sie sehen,
dass ein Suchrequest von Nachbar A für Adresse B gekommen ist, können
sie damit nur ablesen. dass irgendwer hinter A (im Zweifelsfall das
ganze Internet) irgendwas an B schicken will (der es dann wahrscheinlich
auch nur weiterleitet).

Somit kann aus dem Knacken eines großen Knotens keine sinnvolle
Information gewonnen werden, solange es nur genug andere Knoten gibt.
Allenfalls kann man sich Hop für Hop näher an einen bestimmten Sender
oder Empfänger heranarbeiten. Wenn die Hops in verschiedenen
Jurisdiktionen sind, ist das zumindest mühsam.


> >etwas naiv) vor, dass ein Flood-Fill-Verfahren für Suchrequests
> >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,
> 
> wer definiert eine legitime Domain? [1]

Ich :-)

Gemeint war eine Domain (bzw. Adresse) die regelmäßig Mails sendet und
empfängt. Wenn diese Adresse bereits Mails mit jemandem in meiner
Nachbarschaft austauscht (was nicht unwahrscheinlich ist, wenn ich mit
ihr Mails austauschen will) hat sie dieser Nachbar ziemlich sicher im
Cache und ein paar weitere Nachbarn auch. Die Query wird sich also nicht
über das gesamte Netz ausbreiten.

> und wer versucht das Netz lahmzulegen oder hat nur (vorübergehend ein)  
> grosses Mailaufkommen oder eben ein technisches Problem?

Ist egal. Wenn wir beide miteinander peeren, und ich erhalte von Dir
eine Million Queries für verschiedene Adressen, dann ist mir eigentlich
egal, ob Du legitimerweise Mails an eine Million Adressen verschicken
willst, ob Du ein technisches Problem hast, ob Du ein Spammer bist oder
ob einer Deiner Nachbarn ein Spammer ist. In jedem Fall werde ich nicht
eine Million Queries an meine Nachbarn weiterleiten. Die Policy kann
jeder Knoten selbst bestimmen, aber eine relativ vernünftige Policy
erscheint mir z.B. zu sein, alle Anfragen, die sich aus dem Cache
beantworten lassen, sofort zu beantworten, und den Rest in eine Queue zu
stellen, die in gemäßigter Rate (z.B. 1 pro Sekunde) abgearbeitet wird
(mit Round Robin zwischen den Nachbarn, damit Du mit Deiner Million
Abfragen nur Dich selber blockierst und nicht meine anderen Nachbarn).


> >indem er einfach wahllos nach Domains sucht, werden ihm seine Peers auf
> >die Finger klopfen (z.B. durch ein Rate-Limit für Suchrequests).
> 
> auja - und das wird dann mit manchen Peers ähnlich toll laufen wie es  
> heute schon bei Domainübernahmen weg von AON geht.
> Ich stelle mir dann einen Maildomainwechsel echt toll vor.

Das geht dann leichter, weil AON (oder ein anderer wenig kooperativer
Knoten) für meine Nachrichten nur ein Zwischenknoten wie jeder andere
auch ist. Im Gegensatz zu jetzt, wo sie auf meinem[0] MX-Record
draufsitzen und damit im Prinzip meinen gesamten Mail-Verkehr
kontrollieren, hätten sie da keine besondere Rolle mehr. Wenn ich nicht
mehr mit ihnen peere und sie eine an mich adressierte Nachricht
bekommen, können sie eine andere Route zu mir suchen oder die Nachricht
droppen. Im letzteren Fall sollte beim nächsten Zustellversuch (ach ja,
End-to-end delivery notifications hätte ich auch gern, schon deshalb
brauche ich einen Return-Path) eine andere Route gewählt werden und
irgendwann werden dann auch die Routingtabellen angepasst.

> [1] ihr habt solche Fragen von mir bald los, das Vereinsjahr geht nur  
> noch bis Mitte des Jahres.

Hmm. Nicht-Mitgliedschaft bei der VIBE hindert mich nicht daran, Leute
hier mit seltsamen Ideen zu nerven :-).

	hp

[0] Ok, nicht auf meinem. Auf meinen MX-Records sitze ich selber - ich
    weiß, warum ich meine eigenen DNS-Server betreibe.

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

Attachment: signature.asc
Description: Digital signature