Zukunft von SMTP
Daniel Schaedler
Gibt es eigentlich schon einen Nachfolger für SMTP?
Ich habe nicht's wirklich seriöses darüber gefunden.
meine paar Gedanken für SMTP verbesserungen:
- Absender eMail-adresse muss Fälschungssicher (niemand darf mit meiner
Adresse eMails versenden)
- Maildomain muss eigene Mailadressen verwalten können (vor allem sperren)
- rückwärtkompatibel zu SMTP
wie liesse sich das realisieren:
- AbsendereMailadresse wird zusammen mit AbsenderIP und timestamp
verschlüsselt mitübertragen (vorzugsweise vor dem MailBody). [Nur der
Inhaber des
Schlüssels kann verschlüsseln]
- Verschlüsselung vorzugseise mit symetrischen Schlüsseln, da schneller;
aber auch asymetrisch ist möglich
- Empfänger (MTA, MailClient) fragt nun beim Domaininhaber mit angegebener
FROM-Adresse und dem verschlüsselten Text(eMail, IP, timespamt) nach, ob
diese Kombination gültig sei.
- Domaininhaber kann nun entscheiden, ob angegebener Versender erstens
authentisch ist, und zweitens, ob dessen Mailadresse noch gültig ist.
- nur wenn Domaininhaber sein ok gibt, wird Mail weitergeleitet.
Vorteile:
* Absenderadressen lassen sich nicht mehr fälschen
* Filtern auf Spam wird sehr viel einfachen, wenn man sich auf Absender
verlassen kann
(Filter auf Domainebene sind möglich; sogar auf tld Ebene)
* läuft mit 'normalem' smtp zusammen
* open relays sind egal
Probleme:
* geringfügig höherer traffic
* Mailserver müssen leistungsfähiger werden (zusätzlicher Dienst,
Schlüsselverwaltung,
Entschlüsselung)
* Schlüsselverteilung (jeder eMailadresse braucht einen)
* Entwicklung neuer Mailsoftware (sollte keine Hexerei sein...)
* möglichst grossflächige Einführung, sonst bringt's nichts (ist wohl der
Knackpunkt)
bin mal gespannt auf eure Komentare
Daniel
Roland M. Kreutzer
> Gibt es eigentlich schon einen Nachfolger für SMTP?
Leider nein.
> - Maildomain muss eigene Mailadressen verwalten können (vor allem
> sperren)
Was ist daran neu?
> - rückwärtkompatibel zu SMTP
;-) also einen Modus mit den bekannten Schwächen, um die unbeaufsichtigten
koreanischen Server weiter laufen lassen zu können ;-)
> - Verschlüsselung vorzugseise mit symetrischen Schlüsseln, da
> schneller
aha?
> - Empfänger (MTA, MailClient) fragt nun beim Domaininhaber mit
> angegebener FROM-Adresse und dem verschlüsselten Text(eMail, IP,
> timespamt) nach, ob diese Kombination gültig sei.
Besser: Mail bleibt am Absender-Server liegen, nur der Verweis drauf wird
gesendet. Dann muss der Empfänger den Sende-Server kennen, um die Mail
abholen zu können - und der Absender ist gleichzeitig validiert. Pull statt
Push, der Absender hat die Kosten.
BTW: netter Vertipper im "timestamp" *LOL*
> - nur wenn Domaininhaber sein ok gibt, wird Mail weitergeleitet.
Domaininhaber = Spammer?
--
lg. ;-)
Roland M. Kreutzer
www.aufzack.com
Andreas Kretschmer
> meine paar Gedanken für SMTP verbesserungen:
> - Absender eMail-adresse muss Fälschungssicher (niemand darf mit meiner
> Adresse eMails versenden)
Geht heute schon, GnuPG etc. existiert.
> Entschlüsselung)
> * Schlüsselverteilung (jeder eMailadresse braucht einen)
Unrealistisch, weil für den Durchschnitts-WinDAU zu komplex.
> * Entwicklung neuer Mailsoftware (sollte keine Hexerei sein...)
Unrealistisch. Schau Dir Microsofts Ausguck an, seit Jahren bekannte
Fehler sind heute noch nicht gefixt.
> bin mal gespannt auf eure Komentare
> Daniel
Gähn. Schau mir in die Sig, Kleines...
end
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
Hans Peter Stroebel
> - Verschlüsselung vorzugseise mit symetrischen Schlüsseln, da schneller;
> aber auch asymetrisch ist möglich
Soweit ich PGP/GnuPG richtig verstanden habe, wird mit einem symmetrischen
Verfahren verschlüsselt. Nur der Schlüssel selbst wird asymetrisch
verschlüsselt. Was ist also das Problem?
BTW, wie willst Du sonst den symmetrischen Schlüssel übertragen, per
Telefon? Wenn Du ihn asymmetrisch verschlüsselst -> PGP...
Hans
--
Hans Peter Stroebel
hp...@operamail.com
Yes, I do. But not Yahoo.
Dirk Nimmich
> bin mal gespannt auf eure Komentare
Ohne darzulegen, was Du eigentlich willst, läßt sich das schwer
kommentieren. Du möchtest offenbar, daß Absenderadressen über-
prüfbar sind, aber Du schreibst nicht, warum. Vielleicht ist für
Dein eigentliches Ziel eine Änderung von SMTP gar nicht notwendig.
Es würde (Dir) vielleicht auch helfen, wenn Du bei Deinen
Überlegungen einen Vergleich mit der Briefpost ziehen und dabei die
Verhältnismäßigkeit der Mittel bewerten würdest.
Beim Lesen hatte ich außerdem den Eindruck, daß Du SMTP allenfalls
oberflächlich und alternative bzw. ergänzende Formen des
Mailtransports (Beispiel: UUCP) gar nicht kennst. Zudem glaube ich,
daß Du keine Vorstellung davon hast, welche Probleme Du Dir mit
kryptographischen Anwendungen einhandelst. Jedenfalls ist entgegen
Deiner Vermutung die Einführung der Software ein Klacks gegen die
Schwierigkeit, eine funktionierende Kryptographieinfrastruktur zu
etablieren -- und das weltweit.
Bodo Eggert
> Besser: Mail bleibt am Absender-Server liegen, nur der Verweis drauf wird
> gesendet. Dann muss der Empfänger den Sende-Server kennen, um die Mail
> abholen zu können - und der Absender ist gleichzeitig validiert. Pull statt
> Push, der Absender hat die Kosten.
"Ich habe Dir eine Mail geschickt, hole sie bitte von 10.0.0.254 ab...-)"
IMO brauchen wir zuerst SecureDNS mit PKI. Der Rest dürfte sich dann
größtenteils mit Zertifikaten erschlagen lassen, sobald man sich auf
einen(!) Standard geeinigt hat und die Programme Dau-Kompatibel werden.
--
Es ist ja das Ziel jeder Tätigkeit des Intellekts,
ein Wunder in etwas zu verwandeln, was man begreifen kann.
-- Albert Einstein
Adam Diez
Hash: SHA1
Daniel Schaedler <use...@daniel.schaedler.name> wrote:
> Gibt es eigentlich schon einen Nachfolger für SMTP?
Ja, _auth-amtp_ *lol* ...
> Ich habe nicht's wirklich seriöses darüber gefunden.
... weitersuchen und lernen wozu es da ist und wie es funktioniert ...
> meine paar Gedanken für SMTP verbesserungen:
> - Absender eMail-adresse muss Fälschungssicher (niemand darf mit meiner
> Adresse eMails versenden)
Unrealistisch, unnoetig und nicht machbar. Doch! Man kann es vieleicht doch:
Demnaechst gibt es nur noch Micoschrott Rechner, die fertig konfiguriert
verkauft werden auf Bestellung und du hast keinerlei Rechte und Moeglich-
keiten daran etwas zu aendern. Ist das dein Wunsch?
> wie liesse sich das realisieren:
> - AbsendereMailadresse wird zusammen mit AbsenderIP und timestamp
> verschlüsselt mitübertragen (vorzugsweise vor dem MailBody). [Nur der
> Inhaber des Schlüssels kann verschlüsseln]
Nein, nur den _Body_ verschluesseln mit reicht. Es gibt genuegend moe-
glichkeiten um festzustellen ob der Body mit einem DIR bekannten Schluessel
verschluesselt wurde. Die Absenderadresse ist dann egal und es muesste in der
Mail noch nicht mal eine drin stehen. Das gibt es ueberigends *fg* schon ewig
und das Protokoll mit dem es uebertragen wird ist egal. Such mal nach PGP/GPG.
> - Verschlüsselung vorzugseise mit symetrischen Schlüsseln, da schneller;
> aber auch asymetrisch ist möglich
aha ...
> - Empfänger (MTA, MailClient) fragt nun beim Domaininhaber mit angegebener
> FROM-Adresse und dem verschlüsselten Text(eMail, IP, timespamt) nach, ob
> diese Kombination gültig sei.
wozu?
> - Domaininhaber kann nun entscheiden, ob angegebener Versender erstens
> authentisch ist, und zweitens, ob dessen Mailadresse noch gültig ist.
> - nur wenn Domaininhaber sein ok gibt, wird Mail weitergeleitet.
wozu?
> Vorteile:
> * Absenderadressen lassen sich nicht mehr fälschen
> * Filtern auf Spam wird sehr viel einfachen, wenn man sich auf Absender
> verlassen kann
quatsch ...
> (Filter auf Domainebene sind möglich; sogar auf tld Ebene)
> * läuft mit 'normalem' smtp zusammen
> * open relays sind egal
letzteres ist korrekt.
[ rest geloescht ]
> bin mal gespannt auf eure Komentare
Tja, was soll man sagen? Deine Gedankengaenge erregen mich zutiefst und
erzeugen echten Unmut in mir! Hast du dir das alles ausgedacht oder in
einem Microschrott Propagandapapier gelesen? Hast du dir schonmal die
Frage gestellt wozu das alles sein soll und was es bringt? Wenn du sicher
sein willst, das die Mail von einem bestimmten Absender ist, kannst du
PGP verwenden und wie gesagt ist es dann egal was fuer ein Absender
verwendet wird. Deine (etwas wirren) Gedankengaenge produzieren viel viel
mehr Traffic und benoetigen extrem mehr Rechenleistung. Das hast du selbst
festgestellt! Wozu das ganze dann? Wir verdraengen also ein paar Spamer,
haben so Traffic gespart und verbrauchen diese wieder um die Spamer
ueberhaupt verdraengen zu koennen? Ist das nicht wirr?
Ne, zum Schluss kann man nur sagen: Vergiss den ganzen Kram wieder und
lerne mit den dir zur Verfuegung stehenden Mittel umzugehen! Diesen Bei-
trag hier habe ich signiert und du kannst ganz einfach feststellen ob
wirklich _ICH_ diesen geschrieben habe. Ich hoffe du hast verstanden was
ich meine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iQCVAwUBPxj3x67Nul98kegLAQJ6bQP/dAsq5KokY0Abear4d+vkxDY5jF9RCSQf
hk7sqNFqVRxzTRKZ6JnUnvBkgbiLi/IYsyBD6P9xtRSs4daV6TmTmWqnlRQf10RJ
Ko/k4VU3ioOYp/RYqKQwHVcojhTQwXk/Ee5aT22vwTrfDx7Dv83uUAdUNDoKHHDJ
nJQePCq8AI4=
=wqq0
-----END PGP SIGNATURE-----
Rainer Zocholl
>Daniel Schaedler wrote:
>> Gibt es eigentlich schon einen Nachfolger für SMTP?
>Besser: Mail bleibt am Absender-Server liegen, nur der Verweis drauf
>wird gesendet. Dann muss der Empfänger den Sende-Server kennen, um die
>Mail abholen zu können - und der Absender ist gleichzeitig validiert.
>Pull statt Push, der Absender hat die Kosten.
So etwas ähnliches gibt es als "RfC-Draft" unter dem Begriff "secure SMTP".
(Nicht zu verwechseln mit "secure SMTP" das auf SSL beruht)
Auch da wird der Absenderserver -mittels DNS(!)- validiert.
(Was natürlich dazuführen wird, das das Spammer-Pack sich die
DNS-Server eignen wird...)
Das würde sehr effektiv gegen den Missbrauch von offenen Proxies
und zu Zombies gemachten MS-Windows-Drecks-Kisten und sich selbst
verschickende Würmer helfen. (Vorteil: Keine Verschlüsselung,
also auch in Embargostaaten anwendbar).
Würde...
Aber vermutlich haben interssierte Kreise beschlossen, das man
mit Antivirus- und Antispam-Software, die ständige -kostenträchtige-
Updates benötigen, erheblich mehr Reibmachen kann, als einmal das
Verfahren zu verbessern.
Daniel Schaedler
> Ohne darzulegen, was Du eigentlich willst, läßt sich das schwer
> kommentieren. Du möchtest offenbar, daß Absenderadressen über-
> prüfbar sind, aber Du schreibst nicht, warum.
Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen. Könnte man davon
ausgehen, dass die Absenderadresse korrekt ist, liesse sich viel einfacher
filtern. Die Antispamprogramme, die auf Filter oder IP-Adressen basieren,
hinken immer hinterher und verhindern das Versenden unnötiger Messages
nicht. (meines erachtens sollten nicht schon zugeschickte Messages verworfen
werden, sondern das absenden der Spam-Message verhindert werden; das spart
traffic).
Mit den heutigen Protokollen lässt sich das nicht bewerkstelligen. (Der
Einwand, dass sich die Message mit PGP authentisieren lässt ist natürlich
korrekt, doch dann müsste jeder user, der mit eine Mail schreiben will pgp
verwenden. Meine Idee ist nun dass die Betreiber grosser Mailserver
vorschreiben (ich weiss, das klingt nicht so toll...), dass jede Message
eine gültige Absenderadresse haben muss. Das zwingt (autsch!) die User
dieses System einzusetzen.
> Vielleicht ist für
> Dein eigentliches Ziel eine Änderung von SMTP gar nicht notwendig.
> Es würde (Dir) vielleicht auch helfen, wenn Du bei Deinen
> Überlegungen einen Vergleich mit der Briefpost ziehen und dabei die
> Verhältnismäßigkeit der Mittel bewerten würdest.
Dieser Vergleich ist doch etwas schwierig, da Briefpost unidirektional ist.
Natürlich kommt bei meiner Idee etwas zusätzlicher traffic dazu, doch der
Steht in keinem Verhältnis zu dem prognostizierten Spamaufkommen.
> Beim Lesen hatte ich außerdem den Eindruck, daß Du SMTP allenfalls
> oberflächlich und alternative bzw. ergänzende Formen des
> Mailtransports (Beispiel: UUCP) gar nicht kennst.
Da hast Du nicht ganz unrecht...
Doch was bringen die schönsten Erweiterungen, wenn sie nicht eingesetzt
werden? (Allem anschein nach werden sie das nicht, sonst würde ich nicht so
viel Spam erhalten)
Habe auch mal einen Blick auf UUCP geworfen: Scheint ziemlich gestorben zu
sein; wurde Entwickelt, bevor die erste Spammessage erfunden wurde; ist
nicht kompatibel mit heutigem SMTP; (+)Trafficeaufkommen würde sich damit
einschränken lassen.
> Zudem glaube ich,
> daß Du keine Vorstellung davon hast, welche Probleme Du Dir mit
> kryptographischen Anwendungen einhandelst. Jedenfalls ist entgegen
> Deiner Vermutung die Einführung der Software ein Klacks gegen die
> Schwierigkeit, eine funktionierende Kryptographieinfrastruktur zu
> etablieren -- und das weltweit.
Erzähl mal.
anscheinend bin ich da etwas baluäugig. Es geht/ging ja auch mit https bzw.
ssl. Exportschwierigkeiten entstehen auch nicht, da bereits existierende
Technologie verwendet wird.
Daniel
A.G.
>> Zudem glaube ich,
>> daß Du keine Vorstellung davon hast, welche Probleme Du Dir mit
>> kryptographischen Anwendungen einhandelst. Jedenfalls ist entgegen
>> Deiner Vermutung die Einführung der Software ein Klacks gegen die
>> Schwierigkeit, eine funktionierende Kryptographieinfrastruktur zu
>> etablieren -- und das weltweit.
>
> Erzähl mal.
> anscheinend bin ich da etwas baluäugig. Es geht/ging ja auch mit https
> bzw. ssl. Exportschwierigkeiten entstehen auch nicht, da bereits
> existierende Technologie verwendet wird.
Schon mal ein SSL Zertifikat beantragt ? Da musst du ne Menge an
Informationen einreichen um deine Identität zu bestätigen. Kein Benutzer
der mal schnell ne EMail verschicken will würde so einen Aufwand auf sich
nehmen. Den meisten sind ja schon die gängigen EMail Programme zu
kompliziert.
Michael Duergner
> Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen. Könnte man davon
> ausgehen, dass die Absenderadresse korrekt ist, liesse sich viel einfacher
> filtern. Die Antispamprogramme, die auf Filter oder IP-Adressen basieren,
> hinken immer hinterher und verhindern das Versenden unnötiger Messages
> nicht. (meines erachtens sollten nicht schon zugeschickte Messages
> verworfen werden, sondern das absenden der Spam-Message verhindert werden;
> das spart traffic).
Das könnte man schon mit den heute verfügbaren Protokollen erreichen. Z.B.
Mailserver verlagen immer und von jedem (auch von anderen Mailservern)
einen Loginnamen und das zugehörige Kennwert (sprich Mails werden nur noch
per SMTP-Auth) verschickt. Dann weißt du immer ganz genau, wo der Dreck her
kam. Das Problem dabei ist nur, wem überträgst du die Aufgabe des
Loginnamen-Verteilens, denn wirklich Sinn macht das ja nur, wenn alle
Server einen zentrale Stelle verwenden. Dass du dann damit jemanden sehr
sehr viel Macht in die Hände gibst is dir schon klar, oder?
> Mit den heutigen Protokollen lässt sich das nicht bewerkstelligen. (Der
> Einwand, dass sich die Message mit PGP authentisieren lässt ist natürlich
> korrekt, doch dann müsste jeder user, der mit eine Mail schreiben will pgp
> verwenden. Meine Idee ist nun dass die Betreiber grosser Mailserver
> vorschreiben (ich weiss, das klingt nicht so toll...), dass jede Message
> eine gültige Absenderadresse haben muss. Das zwingt (autsch!) die User
> dieses System einzusetzen.
Ja dann aber nochmal die Frage: Was machst du, wenn sich $Spammer einfach
selber einen Mailserver hinstellt? Dann kann er darüber ja auch einfach
alles verschicken, oder hab ich da jetzt deine Idee total falsch
verstanden?
> Dieser Vergleich ist doch etwas schwierig, da Briefpost unidirektional
> ist. Natürlich kommt bei meiner Idee etwas zusätzlicher traffic dazu, doch
> der Steht in keinem Verhältnis zu dem prognostizierten Spamaufkommen.
Hmm das halte ich schon für durchaus diskussionswürdig, ob das wirklich so
ist. Du musst ja außerdem auch noch die Rechenleistung mit berücksichtigen,
die zum Verschlüsseln, etc. verwendet wird.
> Da hast Du nicht ganz unrecht...
> Doch was bringen die schönsten Erweiterungen, wenn sie nicht eingesetzt
> werden? (Allem anschein nach werden sie das nicht, sonst würde ich nicht
> so viel Spam erhalten)
Aha und was veranlasst dich zu der Annahme, dass dieses neue System einfach
jeder einsetzen würde?
> Erzähl mal.
> anscheinend bin ich da etwas baluäugig. Es geht/ging ja auch mit https
> bzw. ssl. Exportschwierigkeiten entstehen auch nicht, da bereits
> existierende Technologie verwendet wird.
Aha hast du dir schon mal angesehen, in welche Länder bestimmte
Verschlüsselungsalgorithmen nicht exportiert werden dürfen? Und die die
exportiert werden dürfen taugen zum Großteil nix.
--
Michael Dürgner
Informatik-Student
Wise men don't need advice. Fools don't take it.
- Benjamin Franklin -
Daniel Schaedler
> Am Sat, 19 Jul 2003 11:35:42 +0200 schrieb Daniel Schaedler:
>
>>> Zudem glaube ich,
>>> daß Du keine Vorstellung davon hast, welche Probleme Du Dir mit
>>> kryptographischen Anwendungen einhandelst. Jedenfalls ist entgegen
>>> Deiner Vermutung die Einführung der Software ein Klacks gegen die
>>> Schwierigkeit, eine funktionierende Kryptographieinfrastruktur zu
>>> etablieren -- und das weltweit.
>>
>> Erzähl mal.
>> anscheinend bin ich da etwas baluäugig. Es geht/ging ja auch mit
>> https bzw. ssl. Exportschwierigkeiten entstehen auch nicht, da
>> bereits existierende Technologie verwendet wird.
>
> Schon mal ein SSL Zertifikat beantragt ? Da musst du ne Menge an
> Informationen einreichen um deine Identität zu bestätigen.
kenn ich.
> Kein
> Benutzer der mal schnell ne EMail verschicken will würde so einen
> Aufwand auf sich nehmen. Den meisten sind ja schon die gängigen EMail
> Programme zu kompliziert.
Es geht ja auch nicht um Zertifikate, sonern nur um Verschlüsselung. Es
weisst Dir lediglich Dein Mailserver einen Schlüssel zu mit dem Du Deine
eMail etc. verschlüsselst. Die einzige Bedingung ist: Versendender
Mailclient muss mit diesem Schlüssel verschlüsseln können und Mailserver
muss den Verschlüsselten Text wieder entschlüsseln können. Noch einfacher,
wenn Du über einen Webclient Deine Mails verwaltest, dann musst Du dich um
gar nichts kümmern, da die Verschlüsselung direkt vom WebClient übernommen
werden kann.
Daniel
Hans- Peter Walther
> Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen.
Die Wurzel ist wohl kaum in der Technik zu suchen, sondern sitzt
in den Köpfen einiger weniger. Also - Rübe ab?
Technik kann immer nur Auswirkungen einschränken bzw.
unterbinden, niemals die Ursache (-> Wurzel) beseitigen.
mfg
Walther
Dominik Ruf
In de.comm.software.mailserver Daniel Schaedler wrote:
> Dirk Nimmich wrote:
>
>> Ohne darzulegen, was Du eigentlich willst, läßt sich das schwer
>> kommentieren. Du möchtest offenbar, daß Absenderadressen über-
>> prüfbar sind, aber Du schreibst nicht, warum.
> Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen. Könnte man davon
> ausgehen, dass die Absenderadresse korrekt ist, liesse sich viel einfacher
> filtern.
Also sowas in der Art gibt es ja schon: Exim kennt z.B. das Feature
"sender-callback", das überprüfen kann, ob der Envelope-Sender
auch tatsächlich existiert und Mails annimmt. Ich habe festgestellt,
dass man damit schonmal einen Großteil des Spams noch _vor_ der
Annahme verhindern kann.
Das setzt allerdings eigene MXe voraus und bei richtig großen
Mailprovidern wird sowas aus Performancegründen wohl nie
eingesetzt werden.
Grüße, Dominik [Fup2 de.comm.software.mailserver]
Dominik Ruf
> Es geht ja auch nicht um Zertifikate, sonern nur um Verschlüsselung. Es
> weisst Dir lediglich Dein Mailserver einen Schlüssel zu mit dem Du Deine
> eMail etc. verschlüsselst. Die einzige Bedingung ist: Versendender
> Mailclient muss mit diesem Schlüssel verschlüsseln können und Mailserver
> muss den Verschlüsselten Text wieder entschlüsseln können. Noch einfacher,
> wenn Du über einen Webclient Deine Mails verwaltest, dann musst Du dich um
> gar nichts kümmern, da die Verschlüsselung direkt vom WebClient übernommen
> werden kann.
Äh... irgendwo hakt es jetzt bei mir. Und was ist, wenn der Spammer
den Müll direkt bei dir einkippt und nicht über den offiziellen
Smarthost seines ISPs geht?
Grüße, Dominik
Dirk Nimmich
> Dirk Nimmich wrote:
>
>> Ohne darzulegen, was Du eigentlich willst, läßt sich das schwer
>> kommentieren. Du möchtest offenbar, daß Absenderadressen über-
>> prüfbar sind, aber Du schreibst nicht, warum.
>
> Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen.
Was hat das mit gültigen, prüfbaren Absenderadressen zu tun? Damit
bekämpfst Du ein Symptom, keine Ursache.
Spam ist ein soziales Problem, kein technisches. Alles in allem habe
ich den Eindruck, daß hier nur wieder eine weitere Diskussion
stattfindet, die soziale Probleme mit technischen Mitteln bekämpfen
will. Das geht bis zu einem gewissen Grad, aber irgendwann muß man
eben hingehen und eine soziale Lösung finden.
Sei's drum, ich werde Dir die technischen Probleme zeigen.
> Könnte man davon ausgehen, dass die Absenderadresse korrekt ist,
> liesse sich viel einfacher filtern.
Guter Witz. Wie denn? Dann werden eben echte Absenderadressen
benutzt, die nur solange gültig sind, bis die Versandaktion beendet
ist. Millionen von Wegwerfadressen zu generieren ist eine Sache von
nichtmal einer Minute.
> Die Antispamprogramme, die auf Filter oder IP-Adressen basieren,
> hinken immer hinterher und verhindern das Versenden unnötiger
> Messages nicht. (meines erachtens sollten nicht schon zugeschickte
> Messages verworfen werden, sondern das absenden der Spam-Message
> verhindert werden; das spart traffic).
Richtiger Ansatz, falsche Umsetzung.
> Mit den heutigen Protokollen lässt sich das nicht bewerkstelligen.
Das wird auch mit zukünftigen Protokollen nicht gehen.
> Der Einwand, dass sich die Message mit PGP authentisieren lässt
> ist natürlich korrekt, doch dann müsste jeder user, der mit eine
> Mail schreiben will pgp verwenden.
Pgp ist doch nur eine Implementation eines Protokolls -- löse Dich
doch einfach mal vom Konkreten und denke allgemeiner darüber nach.
Das Protokoll mußt Du schon vorgeben, sonst funktioniert es nicht.
Bei Deinem Vorschlag müßte ja auch jeder SMTP in der von Dir
gewünschten Erweiterung verwenden, damit es geht.
> Meine Idee ist nun dass die Betreiber grosser Mailserver
> vorschreiben (ich weiss, das klingt nicht so toll...), dass jede Message
> eine gültige Absenderadresse haben muss. Das zwingt (autsch!) die User
> dieses System einzusetzen.
... oder einen eigenen Mailserver zu betreiben, was nicht wirklich
schwierig ist.
>> Vielleicht ist für
>> Dein eigentliches Ziel eine Änderung von SMTP gar nicht notwendig.
>> Es würde (Dir) vielleicht auch helfen, wenn Du bei Deinen
>> Überlegungen einen Vergleich mit der Briefpost ziehen und dabei die
>> Verhältnismäßigkeit der Mittel bewerten würdest.
>
> Dieser Vergleich ist doch etwas schwierig, da Briefpost unidirektional ist.
Briefpost ist genauso unidirektional wie E-Mail. Und für schwierig
halte ich den Vergleich nicht. Wenn Du Dich mit dem Protokoll
auseinandersetzt, wirst Du feststellen, daß die Briefpost sogar fast
1:1 elektronisch in SMTP umgesetzt ist.
> Natürlich kommt bei meiner Idee etwas zusätzlicher traffic dazu, doch der
> Steht in keinem Verhältnis zu dem prognostizierten Spamaufkommen.
Vordringlich geht es mir darum, daß Dir die Konsequenzen klar
werden, was es -- übertragen auf Sackpost, weil das offenbar
leichter zu verstehen ist als E-Mail und die dort verwendeten
Protokolle -- bedeuten würde, wenn man das dort auch täte, und ob Du
das dann noch willst. Würdest Du Dir wünschen, daß Deine lokale
Postfiliale jeden Brief von Dir bestätigen müßte, bevor er
ausgeliefert wird?
Daß Dir dann nebenbei bewußt wird, welchen Aufwand das bedeutet, ist
nur ein gewünschter Nebeneffekt.
>> Beim Lesen hatte ich außerdem den Eindruck, daß Du SMTP allenfalls
>> oberflächlich und alternative bzw. ergänzende Formen des
>> Mailtransports (Beispiel: UUCP) gar nicht kennst.
>
> Da hast Du nicht ganz unrecht...
> Doch was bringen die schönsten Erweiterungen, wenn sie nicht eingesetzt
> werden? (Allem anschein nach werden sie das nicht, sonst würde ich nicht so
> viel Spam erhalten)
Hier ging es mir darum, daß Du -- wie leider viele Leute -- davon
ausgehst, daß der Absender oder Empfänger stets online ist und
angefragt werden kann. Das ist weder immer sinnvoll noch überall
üblich. Mail ist mehr als nur SMTP!
Mail an roxel.ms.sub.org wird zum Beispiel von einem Rechner
verwaltet, der gar nicht online ist. Sie landet erst bei
subnet.sub.net (ist online), dann bei book7.ms.sub.org (ist online,
aber davon weiß der Anfragende nichts) und kommt erst dann zu
roxel.ms.sub.org (ist offline und kann als einziges System Auskunft
über die Gültigkeit einer Adresse erteilen).
> Habe auch mal einen Blick auf UUCP geworfen: Scheint ziemlich gestorben zu
> sein;
Es ist nicht mehr weit verbreitet, stimmt. Das ist aber kein Grund,
davon auszugehen, daß man nur noch SMTP verwenden kann.
> ist nicht kompatibel mit heutigem SMTP;
Selbst wenn das stimmen würde (SMTP über UUCP funktioniert): Das
braucht es auch nicht. E-Mail ist zunächst einmal ein Format. SMTP
und UUCP sind Transportmechanismen.
Das meinte ich, als ich schrieb, daß Du Dich mit dem Thema nur
oberflächlich beschäftigt hast.
> (+)Trafficeaufkommen würde sich damit einschränken lassen.
Aha? Sag an.
>> Zudem glaube ich, daß Du keine Vorstellung davon hast, welche
>> Probleme Du Dir mit kryptographischen Anwendungen einhandelst.
>> Jedenfalls ist entgegen Deiner Vermutung die Einführung der
>> Software ein Klacks gegen die Schwierigkeit, eine funktionierende
>> Kryptographieinfrastruktur zu etablieren -- und das weltweit.
>
> Erzähl mal.
> anscheinend bin ich da etwas baluäugig.
Ja, ziemlich.
> Es geht/ging ja auch mit https bzw. ssl.
Für hinreichend geringe Werte von "geht", ja.
Erstelle doch einfach mal einen SSL-Schlüssel und beantrage ein
SSL-Zertifikat. (Das ist noch einfach.) Und dann mache Dich daran,
alle in Deinem Browser gespeicherten Schlüssel und Zertifikate zu
prüfen -- das müßtest Du nämlich, wenn Du da vernünftig herangehen
wolltest. (Das ist aufwendig, weil es über einen sicheren Kanal
geschehen muß.) Anschließend verteile Zertifikat und öffentlichen
Schlüssel so, daß Manipulationen schnell und sicher entdeckt werden.
(Das ist theoretisch noch recht einfach, aber bei jedem Empfänger
fällt die aufwendige Zertifikatprüfung an. Das, zusammen mit dem
Problem, daß die meisten Leute gar nicht wissen, daß sie so etwas
tun sollten, macht die Sache praktisch undurchführbar.) Und dann
versuche, Zertifikat und Schlüssel zurückzuziehen, weil der
Schlüssel kompromittiert wurde. (Das ist der wichtigste Teil und
praktisch unmöglich, wenn Du die Verteilung nicht kontrollieren
kannst und nicht vorgesehen hast, daß bei jeder (!) Anwendung eines
Schlüssels die Gültigkeit von Zertifikat und Schlüssel erneut
geprüft wird.)
> Exportschwierigkeiten entstehen auch nicht, da bereits
> existierende Technologie verwendet wird.
Von _diesen_ Problemen habe ich dann noch gar nicht angefangen.
Dirk Nimmich
>> Schon mal ein SSL Zertifikat beantragt ? Da musst du ne Menge an
>> Informationen einreichen um deine Identität zu bestätigen.
>
> kenn ich.
Nicht gut genug.
>> Kein Benutzer der mal schnell ne EMail verschicken will würde so
>> einen Aufwand auf sich nehmen. Den meisten sind ja schon die
>> gängigen EMail Programme zu kompliziert.
>
> Es geht ja auch nicht um Zertifikate, sonern nur um Verschlüsselung.
Das hängt unmittelbar miteinander zusammen. Die einzige Ausnahme
ist, daß die Verwender des Schlüssels sich gegenseitig kennen und
vertrauen.
> Es weisst Dir lediglich Dein Mailserver einen Schlüssel zu mit dem
> Du Deine eMail etc. verschlüsselst. Die einzige Bedingung ist:
> Versendender Mailclient muss mit diesem Schlüssel verschlüsseln
> können und Mailserver muss den Verschlüsselten Text wieder
> entschlüsseln können.
Und wie liest der Empfänger die Mail, wenn sie verschlüsselt ist und
nur der Mailserver sie entschlüsseln kann?
Ok -- die Idee, die Du da vorschlägst, ist nicht neu, man macht das
nur anders (und braucht dann SMTP auch nicht zu erweitern). Es
bleibt aber das Problem, daß der Empfängermailserver dem prüfenden
Mailserver vertrauen muß. Das hilft uns nicht weiter, wenn der
Spammer seinen Mailserver selbst verwaltet oder den prüfenden
Mailserver lahmlegt und sich selbst als dieser ausgibt (man in the
middle attack).
A.G.
> A.G. wrote:
>> Am Sat, 19 Jul 2003 11:35:42 +0200 schrieb Daniel Schaedler:
>>
>>>> Zudem glaube ich,
>>>> daß Du keine Vorstellung davon hast, welche Probleme Du Dir mit
>>>> kryptographischen Anwendungen einhandelst. Jedenfalls ist entgegen
>>>> Deiner Vermutung die Einführung der Software ein Klacks gegen die
>>>> Schwierigkeit, eine funktionierende Kryptographieinfrastruktur zu
>>>> etablieren -- und das weltweit.
>>>
>>> Erzähl mal.
>>> anscheinend bin ich da etwas baluäugig. Es geht/ging ja auch mit
>>> https bzw. ssl. Exportschwierigkeiten entstehen auch nicht, da bereits
>>> existierende Technologie verwendet wird.
>>
>> Schon mal ein SSL Zertifikat beantragt ? Da musst du ne Menge an
>> Informationen einreichen um deine Identität zu bestätigen.
>
> kenn ich.
Du hast aber anscheinend noch nicht begriffen warum man das machen muß.
Damit ein Zertifikat vom Browser ohne Probleme anerkannt wird, muß das
Zertifikat von einer Offiziellen Stelle signiert sein. Wenn ich will kann
ich mir mein eigenes Zertifikat ausstellen und und auch selber signieren
aber der Browser gibt dann eine Warnung aus, wenn die Verschlüsselte
Seite aufgerufen wird.
>> Kein
>> Benutzer der mal schnell ne EMail verschicken will würde so einen
>> Aufwand auf sich nehmen. Den meisten sind ja schon die gängigen EMail
>> Programme zu kompliziert.
>
> Es geht ja auch nicht um Zertifikate, sonern nur um Verschlüsselung. Es
> weisst Dir lediglich Dein Mailserver einen Schlüssel zu mit dem Du
> Deine eMail etc. verschlüsselst. Die einzige Bedingung ist:
> Versendender Mailclient muss mit diesem Schlüssel verschlüsseln
> können und Mailserver muss den Verschlüsselten Text wieder
> entschlüsseln können. Noch einfacher, wenn Du über einen Webclient
> Deine Mails verwaltest, dann musst Du dich um gar nichts kümmern, da
> die Verschlüsselung direkt vom WebClient übernommen werden kann.
Was bringt Verschlüsselung gegen Spam ? Nach deiner Beschreibung willst
du eine Vertrauenswürdige Struktur in der man sichergehen kann, daß der
Absenderadresse einer Mail korrekt ist. Das kriegst du nur hin, wenn es
eine Instanz gibt, die die aufgrund von Unterlagen bestätigt, das die
Adresse korrekt ist und die EMail mit einem entsprechenden Schlüssel
signiert wurde. Anders würde jeder Spammer einfach seinen eigenen
Schlüssel für die jeweilige Absenderadresse generieren und nichts wäre
gewonnen.
Dirk Nimmich
> Damit ein Zertifikat vom Browser ohne Probleme anerkannt wird, muß das
> Zertifikat von einer Offiziellen Stelle signiert sein.
Das ist nicht ganz richtig, wird aber leider immer wieder so
verbreitet. Richtig ist, daß das Zertifikat ist eine Signatur ist,
und zwar über die Daten des öffentlichen Schlüssels. Wichtig für die
Anerkennung ist, daß der dafür benutzte Schlüssel (der
Zertifizierungsschlüssel) dem Browser als vertrauenswürdig bekannt
ist. Der Browser macht bei einer Zertifikatsprüfung dann nichts
anderes als zu prüfen, ob die Signatur mit einem als vertrauens-
würdig eingestuften Zertifizierungsschlüssel verifiziert werden
kann.
> Wenn ich will kann ich mir mein eigenes Zertifikat ausstellen und
> und auch selber signieren aber der Browser gibt dann eine Warnung
> aus, wenn die Verschlüsselte Seite aufgerufen wird.
Das müßte richtigerweise heißen: "Wenn ich will, kann ich mit einem
eigenen Zertifizierungsschlüssel ein Zertifikat (eine Signatur über
die tatsächlichen Schlüsseldaten) ausstellen, aber ..." Das macht im
Anwendungsfall aber meist nichts, weil die Benutzer die Meldung
einfach wegklicken ... :-(
Bodo Eggert
> Dirk Nimmich wrote:
> Mein Ziel ist das Probem 'Spam' an der Wurzel zu packen. Könnte man davon
> ausgehen, dass die Absenderadresse korrekt ist, liesse sich viel einfacher
> filtern. Die Antispamprogramme, die auf Filter oder IP-Adressen basieren,
> hinken immer hinterher und verhindern das Versenden unnötiger Messages
> nicht.
Das Problem hast Du immer, PKI wirkt sich nur auf die Greifbarkeit aus.
>> Vielleicht ist für
>> Dein eigentliches Ziel eine Änderung von SMTP gar nicht notwendig.
>> Es würde (Dir) vielleicht auch helfen, wenn Du bei Deinen
>> Überlegungen einen Vergleich mit der Briefpost ziehen und dabei die
>> Verhältnismäßigkeit der Mittel bewerten würdest.
>
> Dieser Vergleich ist doch etwas schwierig, da Briefpost unidirektional ist.
Genau wie email. Der absendende Host braucht nicht _direkt_ erreichbar sein.
Eventuell holt er erst wieder in zwei Monaten die Mails per UUCP vom
Backup-MX. (Ich kenne Setups, bei denen das realistisch ist.)
> Habe auch mal einen Blick auf UUCP geworfen: Scheint ziemlich gestorben zu
> sein; wurde Entwickelt, bevor die erste Spammessage erfunden wurde; ist
> nicht kompatibel mit heutigem SMTP; (+)Trafficeaufkommen würde sich damit
> einschränken lassen.
Es ist immer noch die praktischste Möglichkeit, Mails an Dialup-Netze zu
leiten.
--
Top 100 things you don't want the sysadmin to say:
76. I have never seen it do *that* before...
Daniel Schaedler
> Also sowas in der Art gibt es ja schon: Exim kennt z.B. das Feature
> "sender-callback", das überprüfen kann, ob der Envelope-Sender
> auch tatsächlich existiert und Mails annimmt. Ich habe festgestellt,
> dass man damit schonmal einen Großteil des Spams noch _vor_ der
> Annahme verhindern kann.
Genau sowas in der Art schlage ich ja vor! Nur lässt sich heute der Absender
beliebig fälschen und damit problemlos eine gültige Absenderadresse
einsetzen. Es sollte also noch irgendwie sichergestellt werden, dass der
Absender korrekt ist.
> Das setzt allerdings eigene MXe voraus und bei richtig großen
> Mailprovidern wird sowas aus Performancegründen wohl nie
> eingesetzt werden.
Der zusätzliche traffic ist anscheinend günstiger als leistungsfähigere
Hardware...
Daniel
Michael Duergner
> Genau sowas in der Art schlage ich ja vor! Nur lässt sich heute der
> Absender beliebig fälschen und damit problemlos eine gültige
> Absenderadresse einsetzen. Es sollte also noch irgendwie sichergestellt
> werden, dass der Absender korrekt ist.
Das Problem ist aber auch dann immer noch, wer dafür zuständig ist,
sicherzustellen, dass die E-Mail auch vom richtigen Absender kommt. Sprich,
wer verwaltet die Datenbank, die Siganture und zugehörige E-Mail Adresse
validiert. Wem willst du diese Mscht in die Hände geben?
> Der zusätzliche traffic ist anscheinend günstiger als leistungsfähigere
> Hardware...
Ich denke mal das große Problem ist das o.g.
A.G.
> Dominik Ruf wrote:
>
>> Also sowas in der Art gibt es ja schon: Exim kennt z.B. das Feature
>> "sender-callback", das überprüfen kann, ob der Envelope-Sender auch
>> tatsächlich existiert und Mails annimmt. Ich habe festgestellt, dass
>> man damit schonmal einen Großteil des Spams noch _vor_ der Annahme
>> verhindern kann.
>
> Genau sowas in der Art schlage ich ja vor! Nur lässt sich heute der
> Absender beliebig fälschen und damit problemlos eine gültige
> Absenderadresse einsetzen. Es sollte also noch irgendwie sichergestellt
> werden, dass der Absender korrekt ist.
Daß der Absender existiert bedeutet nicht, daß es auch wirklich die
richtige Adresse des Spammers ist.
Technisch wird man das Problem des Spams nie in den Griff kriegen. Nur auf
sozialer Ebene ist sowas möglich. Wenn keine Produkte mehr gekauft werden
für die in Spams Werbung gemacht wird, entzieht man den Spammern ihre
Grundlage.
Zudem müssen die Auftraggeber der Spammer für den Spam zur
Rechenschaft gezogen werden. Dann bekommen die Spammer auch keine
Aufträge mehr.
Joachim Wehlack
> Dominik Ruf wrote:
>
>> Also sowas in der Art gibt es ja schon: Exim kennt z.B. das Feature
>> "sender-callback", das überprüfen kann, ob der Envelope-Sender
>> auch tatsächlich existiert und Mails annimmt.
Geht das mit Postfix auch? Wenn ja, wie?
>>Ich habe
>> festgestellt, dass man damit schonmal einen Großteil des Spams noch
>> _vor_ der Annahme verhindern kann.
Das ist sicher so. Nur geht diese Massnahme so weit, dass nur
zuständige MTAs einliefern dürfen?
Es gibt sicher Verbesserungsmöglichkeiten. Wie kann man abfragen,
welcher Sender-MTA für einen bestimmten Envelope-Sender zuständig ist?
Der MX-Record ist ja der Empfangs-MTA.
> Genau sowas in der Art schlage ich ja vor! Nur lässt sich heute der
> Absender beliebig fälschen und damit problemlos eine gültige
> Absenderadresse einsetzen.
Eine Abfrage des zuständigen Sender-MTAs würde den Spamer zwingen, T-
Online-Kunde zu werden, wenn er einen (falschen) t-online Envelope-
Sender nutzen will. Wenn der Provider einen Mindeststandard für die
Überprüfung seiner Kunden auf 'Echtheit' umsetzt, wäre so ein Spamer
greifbar.
Und wenn der jeweilige Provider die Echtheit eines Envelope-Senders mit
einer Signatur bestätigt, würde der Spamschutz Anderer bei diesem
Privider sicher keine echten Mails als Spam erkennen.
> Es sollte also noch irgendwie
> sichergestellt werden, dass der Absender korrekt ist.
Das stimmt sicher. Nur die Massnahmen müssen diskriminierungsfrei
umsetzbar sein. Damit ist alles, was zu einer Machtkonzentration führt,
problematisch.
Vor allem wären Massnahmen zu finden, deren Ergebnisse für den
(Mailsendenden) Provider eine Motivation zur Umsetzung wären.
Ein sicheres DNS ist aber die Basis für jede Verbesserung.
mfg
Joachim
Ralf Hildebrandt
> Geht das mit Postfix auch? Wenn ja, wie?
Ja. reject_unverified_sender im Snapshot.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hil...@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix
Dominik Ruf
> Daniel Schaedler schrieb:
>> Dominik Ruf wrote:
>>
>>> Also sowas in der Art gibt es ja schon: Exim kennt z.B. das Feature
>>> "sender-callback", das überprüfen kann, ob der Envelope-Sender
>>> auch tatsächlich existiert und Mails annimmt.
> Geht das mit Postfix auch? Wenn ja, wie?
Keine Ahnung. Postfix ist nicht mein Gebiet.
>>>Ich habe
>>> festgestellt, dass man damit schonmal einen Großteil des Spams noch
>>> _vor_ der Annahme verhindern kann.
> Das ist sicher so. Nur geht diese Massnahme so weit, dass nur
> zuständige MTAs einliefern dürfen?
Nein. Wir sind ja nicht bei GMX, oder? ;-)
Jeder darf mit allem einliefern, wie es ihm beliebt.
> Es gibt sicher Verbesserungsmöglichkeiten. Wie kann man abfragen,
> welcher Sender-MTA für einen bestimmten Envelope-Sender zuständig ist?
Es geht nicht um einen "Sender-MTA". Jeder Rechner darf Mails
zustellen, völlig unabhängig von allem. So steht das in den
RFCs zu SMTP.
> Der MX-Record ist ja der Empfangs-MTA.
Eben. Und bei diesem wird geprüft.
Infos: http://www.exim.org/exim-html-4.20/doc/html/spec_37.html#IX2226
Und dann weiterlesen, Abschnitte 37.13 - 37.17 gehört alles zu diesem
Thema.
So zu verfahren, ist IMHO gar nicht so verkehrt, denn schließlich
ist es meine _Pflicht_, bei Zustellungsproblemen den Absender darüber
zu informieren (es darf ja keine Mail einfach so verloren gehen).
Und wenn der Envelope-Sender bounced, dann könnte ich das ja gar
nicht. Insofern gehe ich lieber auf Nummer sicher und lehne die
Mail in diesem Fall gleich im SMTP-Dialog ab.
Und für Fälle, wo man die Mails trotzdem haben will, kann man
ja Whitelisten definieren. Es gibt z.B. leider viele "Newsletter"
und sonstiges, was von einem user wie z.B. www-...@webserver.example
verschickt wird und was natürlich bounced. Sind halt einfach zu
viele unfähige Leute da draußen im Internet am werkeln, da kann
man nix machen. :-(
Grüße, Dominik
Joachim Wehlack
> Ja. reject_unverified_sender im Snapshot.
Na dann wird es mal Zeit für eine aktuelle Version. Danke.
Joachim Wehlack
> * Joachim Wehlack <weh...@not4spam.de>:
>> Daniel Schaedler schrieb:
>>> Dominik Ruf wrote:
>>>
>>>>Ich habe
>>>> festgestellt, dass man damit schonmal einen Großteil des Spams
>>>> noch _vor_ der Annahme verhindern kann.
>> Das ist sicher so. Nur geht diese Massnahme so weit, dass nur
>> zuständige MTAs einliefern dürfen?
>
> Nein. Wir sind ja nicht bei GMX, oder? ;-)
> Jeder darf mit allem einliefern, wie es ihm beliebt.
Ich habe den Daniel im Ursprungsposting so verstanden, dass es ihm um
Verbesserungen der jetzigen Situation geht.
>> Es gibt sicher Verbesserungsmöglichkeiten. Wie kann man abfragen,
>> welcher Sender-MTA für einen bestimmten Envelope-Sender zuständig
>> ist?
>
> Es geht nicht um einen "Sender-MTA". Jeder Rechner darf Mails
> zustellen, völlig unabhängig von allem. So steht das in den
> RFCs zu SMTP.
Verbesserungen haben langfristig immer eine Erneuerung der RFCs zur
Folge. Das braucht man auch nicht extra zu erwähnen, wenn man über
Verbesserungen spricht. Daher ist eine Argumentation wie 'Änderungen
verstossen gegen bestehende RFCs' unbrauchbar.
>> Der MX-Record ist ja der Empfangs-MTA.
>
> Eben. Und bei diesem wird geprüft.
Sicher. Aber was bei diesem geprüft wird, steht zur Debatte. Und die
gängigen RFCs unterstützen das Versenden von Spam. Und sie unterstützen
das Fälschen des Envelope-From.
Das ist wirklich verbesserungsbedürftig. Eine Einführung von
'Zuständigen Sende-MTAs' würde das Spamaufkommen verringern.
> So zu verfahren, ist IMHO gar nicht so verkehrt, denn schließlich
> ist es meine _Pflicht_, bei Zustellungsproblemen den Absender
> darüber zu informieren (es darf ja keine Mail einfach so verloren
> gehen). Und wenn der Envelope-Sender bounced, dann könnte ich das ja
> gar nicht. Insofern gehe ich lieber auf Nummer sicher und lehne die
> Mail in diesem Fall gleich im SMTP-Dialog ab.
Das ist schon klar. Aber unbrauchbar, wenn der Falsche einen Bounce
erhält, weil du eine Mail mit gefälschen Absender angenommen hast.
Die Frage war ja, wie man das Fälschen des Absenders verhindern kann.
Mit den jetzigen RFCs geht das garnicht, weil diese RFCs ja das
Fälschen von Absendern unterstützen.
Aber man kann ja dennoch mal darüber nachdenken, was man tun könnte, um
diesem Ziel näher zu kommen.
mfg
Joachim
Rolf Krahl
>
> (meines erachtens sollten nicht schon zugeschickte Messages
> verworfen werden, sondern das absenden der Spam-Message verhindert
> werden; das spart traffic).
Das kann prinzipiell nicht funktionieren. Spam sind vom Empfänger
nicht erwünschte Mails[1]. Was der Empfänger wünscht und was nicht,
das kann nur der Empfänger beurteilen. Folglich kann auch nur der
Empfänger prüfen, ob es sich bei einer Mail um Spam handelt oder
nicht. Und deshalb, muß die Mail[2] erst zum Empfänger[3]
transportiert werden, ehe man ihren Charakter überhaupt erst prüfen
kann.
[1]: Ja, diese Definition ist unpräzise formuliert. Setze eine
geeignte Definition von "nicht erwünscht" ein, damit es stimmt.
[2]: Genauer: So viele Information über die Mail, wie der Empfänger zu
dieser Prüfung braucht.
[3]: Genauer: In den Einflußbereich des Empfängers, dort wo diese
Prüfung ggf. vorgenommen wird.
--
Rolf Krahl <rolf....@gmx.net>