Archiv verlassen und diese Seite im Standarddesign anzeigen : Projektidee - SAC Sender Address Confirmation against SPAM
Mir ist eine neues Konzept eingefallen und ist meiner Meinung nach für Server genauso aufwendig wie SPF.
Wo kann ich solche Ideen an den richtigen Ort Posten?
Hier meine Idee:
http://img521.imageshack.us/img521/8493/projektideesacda4.th.gif (http://img521.imageshack.us/my.php?image=projektideesacda4.gif)
Bitte um technische Antworten betreffend möglicher Umsetzungsschwierigkeiten.
Wo und wann wird Passwort herbeigezaubert?
Wo kann ich solche Ideen an den richtigen Ort Posten?
gerne hier, aber genauer ausarbeiten. dann kann man auch konstruktive kritik anbieten, v.a. wenn du Vorteile/Unterschiede gegenüber SPF oder DKIM nennst.
Was für ein Kennwort nutzt Du da und was sind die Kriterien für True/False?
ORB
MagicFridge
22.01.2008, 15:59
Was für ein Kennwort nutzt Du da und was sind die Kriterien für True/False?
So wie ich das verstanden habe, das gleiche Kennwort das auch der User zum einloggen auf dem Mailserver verwendet. Kriterium wäre dann ob die überlieferte Passwort (als md5) mit dem auf dem Mailserver übereinstimmt.
Für einen Einzelfall natürlich leicht zu umgehen in dem das "Spamopfer" irgendwie dazu gebracht wird dem "Spamtäter" eine Mail zu schreiben, da es bei Spam aber ja normalerweise eher auf die Masse ankommt sollte das unerheblich sein... für viel gefährlicher halte ich da die Möglichkeit, den erhaltenen Hash zu cracken...
so long
Das heißt, jeder Mailserver muß jedes Kennwort kennen und vergleichen können?
Währe schön, wenn der OP was dazu sagen würde.
ORB
Das heißt, jeder Mailserver muß jedes Kennwort kennen und vergleichen können?
Währe schön, wenn der OP was dazu sagen würde.
ORB
Nein, ich hatte es mir schon so vorgestellt wie MagicFridge es geschreiben hat.
Natürlich muss alternative zur md5 geschaffen werden. Wäre nämlich nicht sehr sinnvoll, sein Benutzerpasswort ständig (auch wenns verschlüsselt) mit gleicher md5sum zu versenden.
Nochmal zur Kommunikation: der Benutzer verschickt mit SMTP über seinen verantwortlichen Mailserver. Dieser Mailserver kennt ja die Benutzer- Zugangsdaten und würde einen Parameter im SMTP Protokoll ergänzen (oder halt auch über EHLO!?). Der Ziel MX - Server stellt dann eine Verbindung mit dem Mailserver des Absenders auf und prüft den verschlüsselten md5key (oder sonstiges, PGP?!) mit den verschlüsselten Daten des Benutzerkontos.
Ist der Key vom MX - Server gleich dem vom Mailserver des Absenders, leitet der Ziel - MX die Email weiter in das Empfänger Postfach, ansonsten wird sie eben gedropped oder ein schleife für 3 Tage (wegen mögl. Kennwortänderung)
Ein erster vorteil gegeüber SPF ( Gibt bestimmt noch mehr :-)):
+ Einmaliger administrativer Aufwand, anschließend automatisierter Verlauf.
Nachteil:
- Cracker könnte möglicherweise den schlüssel knacken, VIELLEICHT könnte es auch eine Art TICKET sein, das eh abläuft.
hahaha. *scnr
btw, gegen spam z.b. gibt es einen imho recht wirkungsvollen mechanismus,
genannt teergrube. sollte häufiger eingesetzt werden..
gerne hier, aber genauer ausarbeiten.
Da kann ich es gleich an der Kirchentür anschlagen, da kann ich genausoviel brauchbares Feedback erwarten.
Hier kriegt man nichtmal den Hinweis, dass und warum es viel mehr Sinn macht, HMAC zu benutzen statt plain md5.
Oder dass und warum es Sinn macht, die IP zusätzlich kryptomäßig miteinzubeziehen, indem man etwas a la
EHLO <ip, timestamp>@<hmac{ip, ':', timestamp, H{username, ':', realm, ':', passwort)})
macht.
Sowas hätte ich von DIR erwartet. Oder auch nicht.
Wenn man es ernst meint, wird man es ausarbeiten, von halbwegs kompetenten Leuten checken lassen und dann gucken, wer von den DKIM-Leuten einen auseinander nimmt.
Jegliche Absenderverifizierung in SMTP scheitert sowieso einzig und alleine daran, dass es ein Feature von SMTP ist, über einen anderen Mailserver als den eigenen zu versenden.
Jegliche Absenderverifizierung in SMTP scheitert sowieso einzig und alleine daran, dass es ein Feature von SMTP ist, über einen anderen Mailserver als den eigenen zu versenden.
ne da täuschst du dich fip, jedes relay trägt sich schließlich in eine
header variable (liste) ein- wenn man den ersten nimmt ist man wieder
beim ursprung.
liste fakebar? jo, aber dann wird auch gedroppt -> also korrekt.
aaaaber..
<kuchen> und ich kann jetz scho sagen dass es ne scheiß idee is
<kuchen> weil ich würde niemals das passwort, dass ich auf dem weg zu meinem email server schon einmal zuviel übertrag
<kuchen> über mehrere relays versenden
<kuchen> und jedem empfänger teile meiner zugangsdaten senden
<kuchen> von der fehlenden sinnhaftigkeit gegen spam mal ganz abgesehen, as far as i can see
<kuchen> ich hab mal "spaßeshalber" auf ne spam geantwortet und die adresse existierte- sprich no fake addr -> kein reject
wie gesagt, propagier lieber teergrube.
im übrigen ist die Idee von XMPP längst realisiert. Nennt sich dort 'Server Dialback'. RFC 3920, http://www.xmpp.org/extensions/xep-0185.html sowie http://www.xmpp.org/extensions/xep-0220.html
Und die IETF fand das ganze 2004 nicht akzeptabel.
im übrigen ist email asynchron; und damit nochmal weniger geeignet
für dialback im gegensatz zur synchronen kommunikation wie bei jabber. :)
sprich da email stateless ist, ist immer ne rückverbindung nötig (was sich manchmal nichtmal machen lässt)
und am ende beanspruchts noch mehr traffic und ressourcen - bei jeder spam-mail, die eh nicht gedroppt wird weil
der absender account echt ist..
fip fip, hurra!