[linux-l] RFCs und Vorschlaege...

Di Okt 7 20:44:27 CEST 2003

Peter Ross wrote...

> On Mon, 6 Oct 2003, Christoph Biedl wrote:
> 
> > Peter Ross wrote...
> >
> > > Eine Aenderungsidee:
> >
> > Vorab:
> > http://www.rhyolite.com/anti-spam/you-might-be.html
> 
> Klar;-) Nein, dies war nicht das Ei des Kolumbus und ich bin auch kein
> Anti-Spam-Experte. SMTP geht so (acht Jahre Admin, sendmail, smail,
> postfix, fetchmail, procmail, spamassasin kenn ich und nicht nur vom Namen
> her;-)

Isjagut. Ich wollte nur allen Beteiligten klarmachen, daß schon viele
Vorschläge als FUSSP starten und nicht sehr weit kamen, also das Problem
keine einfache Lösung hat, denn sonst wäre sie schon längst eingeführt.

Nachdem - glaubeich - von Deinem Vorschlag nicht mehr viel übrig geblieben
ist, schreibe ich erstmal ein paar Ideen auf, die ich von einem SMTP-
Nachfolger will. Wobei es wahrscheinlich mit etwas in der Qualität von
"Pick any two but you can't have all three" endet.

1 Leichte Senderanonymität: Wenn ich eine Email schicke, soll der
  Empfänger nicht sofort meinen Namen, Anschrift, Telefon etc. ermitteln
  können; andererseits soll eine Rückverfolgung bei Straftaten möglich
  sein, wenn der Vorfall hinreichend eskaliert wird. Der Status Quo mit
  IP-Nummer im Header und Datenherausgabe auf Richterbeschluß ist da
  IMHO durchaus eine brauchbare Konstruktion.
2 Volle Empfangsanonymität: Der Sender darf nicht automatisch erfahren,
  daß ich die Email bekommen habe, wann ich sie bekommen habe. Das
  leistet SMTP sehr gut, auch wenn manche Mailreader automatische
  Empfangsbestätigungen verschicken oder HTML-Mail bei der Anzeige
  eine individuelle Seite aufrufen; aber das ist kein Problem des
  Protokolls sondern des Mailreaders.
disclaimer: Wie immer bei Anonymität gilt auch hier: Wenn der Beteiligte
seine (partielle) Anonymität aufgeben will, bleibt ihm das selbst
überlassen.

3 Offenheit: Es soll möglich sein, einem Empfänger ohne große Klimmzüge
  eine Nachricht zukommen zu lassen, ohne daß vorher eine Kommunikation
  oder eine Absprache darüber stattgefunden hat.
4 Selbstregulierung: Sanktionierung nach Mißbrauch sollte nach Möglichkeit
  im Netz selber stattfinden. Das über Gerichte regeln zu wollen, hat
  einen Haufen Nachteile: Es müssen Gesetze gemacht werden von Leuten, die
  wenig davon verstehen; es müssen Richter urteilen, die (zu oft) wenig
  davon verstehen und die genug anderes zu tun haben; es kann von
  mächtigen Menschen/Konzernen als Druckmittel benutzt werden.

im2000 und Konsorten verletzen (2), und deswegen halte ich davon nichts.
Zwar könnte man die Zwischenlagerung an einen Treuhänder abgeben, aber
erstens hat dann der die Kosten für die Zwischenlagerung und zweitens
dürften sich diverse Schlapphüte und ähnliches dafür sehr interessieren.
So etwas wie "single point of failure" gibt's dann auch noch.

Verzichtet man auf (3), ist man recht schnell bei TMDA, das vielleicht
noch durch ein kryptographisches Kennzeichen erweitert wird, weil ja
From: nicht wirklich viel taugt. Dann muß man sich erst einmal auf die
eine oder andere Weise authentifizieren.

(...)

So, und da kam ich dann in eine sehr ausgiebige Diskussion zu diesem und
verwandten Themen. Ich nehme den Faden jetzt mal nicht mehr auf, es ist
spät und ich habe Hunger :)

Also mal als Abschätzung: SMTP ist tot, eine brauchbare Alternative ist nicht
in Sicht. Die Aufrüstung mit diversen Verifikationen wie z.B. "Gibt es einen
MX oder A für die Domain im Envelope-From:?", treibt den Aufwand hoch, löst das
Problem nicht, schiebt nur den Zeitpunkt für einen Wechsel nach hinten und
schafft bis dahin ein paar schnuckelige andere Probleme. Die nächste
Eskalationsstufe "callback" (milter-sender) läßt sich fein DoSen und danach
wird man vielleicht endlich erkennen, daß jede fälschbare Information im Dialog
und im Header besser auch als gefälscht anzunehmen ist.

Bleibt nur noch eine Sache: Die Einlieferer-IP (BGP-hijacking ist noch immer
ziemlich unüblich). Also wird man im Zweifelsfall nur noch von
vertrauenswürdigen IPs Email annehmen, der Rest muß draußenbleiben. RBL sind
ein Weg dorthin. Die Betreiber von RBLs sind aus durchsichtigen Gründen auch
schon heftigen Attacken ausgesetzt, also muß man sich sowas wohl auch noch
selber stricken. Vielleicht nutzt man das web of trust aus PGP/GPG um in
gleicher Weise ein Netzwerk vertrauenswürdiger Hosts zu bauen. Oder man geht
wieder auf die klassische Sackpost, in Webforen oder kommuniziert nur noch
innerhalb seiner community.

Schöne neue Welt.

	Christoph

> 
> 
> > > Der Anfang einer e-Mail-Konversation waere eine Anfrage - darf ich Deinen
> > > Key haben?
> >
> > .. und wie stellst Du diese Anfrage zu, ohne daß das für junk mail
> > mißbraucht wird (btw, Spam ist was anderes)?
> 
> Ich selbst kann bestimmen, auf eine mir genehme Art und Weise, wie ich
> angesprochen werden moechte.
> 
> Z.B. bekommst Du mit meiner e-Mail-Adresse eine temporaere Webseite mit
> einem Key und kannst mir dann schreiben.
> 
> Es duerfte einem Spammer schwerfallen, dass zusammenzubringen, zumal es
> mir leicht ist, verbal noch zu sagen, das ich die erste und die zweite
> Zeile vertauscht habe.
> 
> Alles so nicht Geschriebene andere fliegt raus.
> 
> > > Die Mailinglisten waeren etwas problematisch. Eventuell einfach von Push
> > > auf Polling umstellen - d.h. ich "ziehe" die Mails von dem Listenserver.
> >
> > im2000 von djb (nicht, daß ich von der Idee viel halte).
> 
> Warum nicht?
> 
> Ich kann obiges Verfahren nicht fuer Mailinglisten verwenden - also gehe
> ich aktiv zum Listenserver.
> 
> Sollte in der Regel klappen. Immerhin stammt SMTP noch aus einer Zeit mit
> UUCP und die Standleitung war noch nicht erfunden (oder nur an der Uni;-)
> Diese Einschraenkung duerfte zumindest fuer die Serverwelt nicht mehr so
> fuerchterlich sein. Und wenn ich eine Mailingliste nicht erreiche, bricht
> die Welt auch nicht zusammen.
> 
> Gruss
> Peter
> 
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> Die Mailingliste der BeLUG (Berliner Linux User Group)
> 
> Wenn du diese Mailingliste  abbestellen willst, gehe bitte auf
> https://mlists.in-berlin.de/mailman/listinfo/linux-l
> und trage dich dort bitte aus