|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
--- schnipp ---
Mit der Integration von verschiedenen Sender-Authentifizierungs-Technologien in diese Applikationen zielt Sendmail darauf ab, die weltweite Verbreitung von Mainstream-Authentifizierungsverfahren wie DomainKeys, das kürzlich von Yahoo vorgestellt worden ist, sowie andere Initiativen unter anderem von Microsoft zu beschleunigen.
--- schnapp ---
Und all diese Technologien taugen nix, denn entweder sie machen Mailinglisten und user mit eigenen Domains welche aber die Mails über den SMTP ihres aktuellen $ISP senden nicht mehr benutzbar, oder sind einfach durch die Spamer zu umgehen.
Was mich allerdings etwas erstaunt ist der Begriff 'Sender Authentifizierung'. Mit SPF und dergleichen gibt es keine Authentifizierung, dazu wäre SMTP-Auth notwenidig und das macht keinen Sinn, wenn man Mail von jedem beliebigen Server oder Benutzer empfangen können soll.
/me macht sich jetzt mal auf die Suche, ob irgendwo eine Referenz zur Original Nachricht von sendmail inc zu finden ist.
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
Danke, das hilft schonmal weiter...
Nachteil ist halt das das nicht viel hilft. Entweder man nimmt nurnoch Mails von Rechnern mit Domainkey an und schneidet sich damit selbst vom Netz ab (dann kann es aber immernoch ein Spammer dort sein), oder es ist wirkungslos.
Vor allem, Wenn Yahoo da mitmacht, dann hilft es garnichts. ein Yahooaccount ist schnell eingerichtet, und man kann schonmal anfangen zu spamen.
Griss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When an email message is received from a particular domain, the receiving system verifies the signature with the sender's public key that is published in the public Domain Name System ("DNS").
So weit so gut. ABER: Entweder ist das Cryptoverfahren so miserabel wie bei den DVDs, oder die Mailserver werden in Zukunft eine verdammt grosse CPU brauchen.
After testing is concluded, Sendmail, Yahoo! and other industry leaders plan to develop an open source package that will allow many different email systems to generate and validate DomainKeys' authentication information.
Irgendjemand wird die Keys validieren muessen. Vermutlich wird sich Verisign dieses Geschaeft schnappen? So 100-500$ pro Mailserver und Jahr duerften da locker dabeisein. Und wie steht es mit Revocation Lists? Ein signierter Mailserver, der ploetzlich Spam relayt, sollte ja irgendwie erkennbar sein. Also bei jeder Mail Verisign rasch anfragen, ob der praesentierte Key auch noch gueltig ist? Das wird Verisign noch mehr in Grund und Boden stampfen als ihr Sitefinder :-)
Lassen wir uns ueberaschen!
I saw screens of green, red messages too, then came blue, shubidu
And i think to myself, what a wunderful world
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 25. February, 11:17 MEW (#8)
|
|
|
|
|
Du hast zwei Dinge missverstanden:
- Die Schlüssel werden nirgends zentral validiert. Der Domaininhaber generiert einen Schlüssel und publiziert den Public-Key per DNS. Die Authentizität des Schlüssels wird nicht per Zertifizierung sondern per DNS-Abfragen gewährleistet (d.h. wer Kontrolle über die DNS einer Domäne hat, entscheidet, welche Schlüssel für diese Domäne gültig sind)
- Eine explizite Revocation gibt es nicht und braucht es auch nicht. Entscheidet der Domainbetreiber, dass ein Schlüssel nicht mehr gültig ist, so entfernt er ihn ganz einfach aus seiner DNS-Zone - voilà.
Für das Verfahren gilt das gleiche wie für andere ähnliche Verfahren (z.B. SPF): Es stellt sicher, dass der Absender durch den Inhaber der Absenderdomain autorisiert wurde, diesen Absender zu nutzen, nichts sonst.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 25. February, 09:25 MEW (#5)
|
|
|
|
|
Und all diese Technologien taugen nix, denn entweder sie machen Mailinglisten
Welches der Verfahren funktioniert nicht mit Mailinglisten? Die meisten der Verfahren verhindern (leider) ein simples "forward" (z.B. per .forward oder Aliases-Eintrag), aber wer das als Mailingliste bezeichnet dürfte nicht verstanden haben, wieso "richtige" Mailinglisten-Server wie Mailman oder Majordomo etwas mehr als dies machen.
und user mit eigenen Domains welche aber die Mails über den SMTP ihres aktuellen $ISP senden nicht mehr benutzbar
Niemand hindert Dich, z.B. bei SPF Den Server Deines $ISP als authentische Quelle einzutragen. Du solltest Dich aber schon auf ein paar wenige Server einschränken - d.h. wenn Du viel unterwegs bist, dann ist es Zeit Deinen eigenen Mailserver mit SMTP-Auth zu haben. Na und? Wenn Du Deinen Mailserver selber betreibst, dann ist das eine Sache von ein paar Stunden, wenn nicht, dann wird Dein Provider sicher gerne auch eine Lösung für ausgehende Mails anbieten.
Bei den kryptographischen Verfahren ist es meist (IMHO) sogar so, dass Du einfach nur den Schlüssel brauchst und einen Mailer, der Mails entsprechend signieren kann (d.h. im einfachsten Fall einfach einen Mailserver auf Deinem Notebook)
oder sind einfach durch die Spamer zu umgehen
Keins der Verfahren, die im Moment ernsthaft im Gespräch sind, ist einfach zu umgehen. Allerdings sollte man sich daran erinnern, dass es hier um die Verifizierung des Absenders geht, nicht um einen Spam-Filter. Das mittelfristige Ziel dieser Vorschläge ist es, Spammer (resp. ihre Helfershelfer) identifizieren zu können, nicht Spam zu verhindern. Ihre Wirkung entfalten diese Massnahmen nur in Verbindung mit anderen - also z.B. einem Spamfilter, der Mails von identifizierten Spammern blockt, oder einer griffigen Gesetzgebung, die es ermöglicht, auf dem rechtlichen Weg gegen Spammer vorzugehen.
Die (maschinelle!) Identifizierbarkeit ist dabei erst mal ein grosser Schritt vorwärts in die richtige Richtung, auch wenn's kurzfristig nur heissen mag, dass auf meinen Mailkonten neben den 500 Spam-Mails pro Tag nicht auch noch ein paar 1000 Bounces von Spam-Mails landen, die durch wohlmeinende Spammer mit meiner E-Mailadresse als Absender versehen werden.
Was mich allerdings etwas erstaunt ist der Begriff 'Sender Authentifizierung'. Mit SPF und dergleichen gibt es keine Authentifizierung
Doch, natürlich, nur handelt es sich nicht um eine Benutzerauthentifizierung, sondern um eine Authentifizierung und Autorisierung des Mailservers. Eine Authentifizierung läuft nach dem Muster: "Gib mir etwas, das Deine Authentizität bestätigt". Im Falle von SPF ist dieses "etwas" typischerweise die IP-Adresse. Was auf viele Leute etwas verwirrend wirken mag, ist, dass Authorisierung und Authentifizierung im Falle von SPF nicht klar getrennte Mechanismen sind.
Also, wenn mein Mailserver eine Nachricht von einer SPF-geschützten Domain bekommt, dann muss der sendende Mailserver sich ausweisen um seine Berechtigung, Mails mit dieser Absenderdomain zu verschicken zu beweisen. Die Ueberprüfung dieses Ausweises erfolgt dabei über die DNS-Einträge der Absenderdomain. Falls diese Spam zulassen kann ich als Spam-Empfänger gezielte Gegenmassnahmen ergreifen. Das passt wunderbar ins Internet mit einer Art "distributed responsibility" ...
|
|
|
|
|
|
