[linux-l] Adress-Missbrauch durch SPAMmer - wie stoppen?

Mi Mai 30 21:13:57 CEST 2007

Hi,

also X.400 kann das schon seit Jahrzehnten. Aber es ist ja ein
ISO-Protokoll und wird damit von vielen Leuten als "Boese"
eingestuft.

Gruss

Ihno

On Wed, May 30, 2007 at 03:45:47AM +0200, Frank Reker wrote:
> Am Fri 25. May 2007 06:39 +0200 schrieb Volker Grabsch:
> 
> >Ein "verbessertes SMTP" ist mir aber auch nicht bekannt, au??er
> >vielleicht Jabber. ;-)
> 
> nuja, seit ein paar jahren ist in italien ein system namens pec
> im kommen. bislang allerdings lediglich im buisiness und government
> bereich eingesetzt. _technisch_ steht allerdings auch einem 
> masseneinsatz nix im wege.
> pec steht fuer Posta Elettronica Certificata (zertifizierte ePost).
> ich hab aehnliche projekte auch schon in deutschland gesehen, erinnere
> mich aber nicht mehr unter welchem namen.
> pec ist eine mischung aus smtp und smime. wobei aber die zertifizierung
> vom pec-server vorgenommen wird, so dass sie fuer den client transparent
> ist.
> beim versenden verbindet sich der client via smtp mit dem pec-server
> (smtp-authentifizierung ist natuerlich pflicht). serverseitig hat
> jeder user ein eigenes zertifikat. der pec-server ueberprueft die
> absenderadresse ob sie mit der im zertifikat uebereinstimmt. wenn
> nicht verweigert er entweder die annahme oder aendert sie eigenmaechtig
> (je nach konfiguration und produkt). dann verpackt er die urspruengliche
> mail in einen envelope, unterschreibt diese mit dem zertifikat des
> users und schickt sie dann ueber normales smtp zum empfaenger. dieser
> ueberprueft die unterschrift und die absenderadresse und wenn korrekt
> wird die mail zugestellt und ein ACK an den absender versendet. 
> falls sie nicht korrekt ist, oder die zustellung fehlschlaegt (z.b.
> ein voller briefkasten) wird ein NACK gesendet. wenn innerhalb von
> 24h kein (N)ACK vom empfaenger kommt wird die uebertragung als
> fehlgeschlagen gewaertet und der pec-server des absenders reicht
> ein NACK an den absender weiter. diese (N)ACKs sind speziell
> formatierte emails, die entweder vom menschen gelesen werden koennen,
> oder auch elektronisch vom mail-client ausgewertet werden koennen.
> 
> der vorteil ist, dass der absender weiss ob und wann die mail
> angekommen ist (natuerlich weiss der absender nur, dass sie 
> zugestellt wurde, nicht ob der empfaenger sie auch gelesen hat).
> und der empfaenger kann sicher sein, dass der absender korrekt ist,
> und die mail nicht veraendert wurde.
> ein weiterer vorteil ist, dass das protokoll komplett transparent
> fuer den klient ist, und somit jeder mailclient (auch webmailer)
> weiter genutzt werden koennen. lediglich der mailserver muss
> angepasst werden. wobei der pec-server nur ein zwischenglied
> ist, die eigentliche mailzustellung uebernimmt dann nach wie
> vor ein herkoemmlicher smtp-server (z.b. postfix). 
> 
> aus beweisgruenden kann der pec-server die empfangenen mails
> fuer eine konfigurierbare zeit aufbewahren (inklusive unterschrift),
> denn die zugstellte mail ist ja dann ohne unterschrift und envelope.
> 
> nachteil ist, dass pec ein geschlossenes system ist, d.h. nicht
> zertifizierte mails, oder mails mit nicht verifizierbaren
> zertifikaten werden abgewiesen. um das ganze global nutzen zu
> koennen bedarf es also auch eine globale zertifizierungsinfrastruktur.
> diese gibt es aber bereits fuer ssl. und da die zertifikate fuer
> ssl und smime die selben sind (lediglich der dn aendert sich),
> stellt dies also lediglich ein finanzielles problem dar, da solche
> zertifikate nicht kostenlos sind. allerdings wuerden bei einem
> masseneinsatz die preise ziemlich schnell purzeln.
> 
> natuerlich stellt pec noch kein spamschutz dar, aber ein schutz
> vor adressfaelschungen. und wer mit seinem richtigen namen
> spamt, der landet auch schnell auf black-lists. und in laendern
> in denen spam illegal ist (wie deutschland) koennte man zudem
> rechtlich gegen spammer vorgehen (beweise hat man ja dann).
> 
> geben tut's pec bereits, im einsatz ist es auch schon. von
> einer kritischen masse sind wir allerdings noch _weit_ entfernt.
> bislang gibt es nur einzelne inselloesungen mit pec.
> 
> 
> >Womit wir wieder beim Thema w??ren: Absenderf??lschung kriegt man meiner
> >Meinung nach nur durch Kryptographie ordentlich in den Griff. Und da
> >hat man eben das Grundproblem, dass man nicht mehr von wildfremden
> >Leuten angeschrieben werden kann, was man aber eigentlich auch m??chte.
> 
> weiss nicht. also wenn ich die erreichbarkeit von jedermann nicht
> beruflich braeuchte wuerd ich mit whitelists arbeiten, und fuer alle
> anderen dann ein web-interface zur verfuegung stellen (solche werden
> bislang von spammern noch  nicht missbraucht). wenn ich will koennt
> ich betreffende personen nach dem erstkonntakt ja dann in die whitelist
> mit aufnehmen. da ich die erreichbarkeit von jedermann aber leider
> beruflich brauche, faellt diese moeglichkeit aus.
> bin aber zur zeit am ueberlegen, ob ich mir ein solches system nicht
> fuer mein heimtelefon installiere, da die werbeanrufe langsam
> unertraeglich werden. mein fax musste ich bereits abschalten, und
> schalte ich nur noch auf vorherige telefonanfrage ein.
> 
> und wo ich schon bei anderen medien bin die zum spammen missbraucht
> werden koennen - richtig nervig sind auch spams via sms. ich war
> mal kunde von tim (telecom italia mobil) bin aber aufgrund massenhafter
> spam-sms schnell wieder zu vodafone zurueckgewechselt. die telecom 
> italia hat sogar ein webportal mit dem firmenkunden werbesms in massen
> an tim-kunden versenden koennen. seit froh, dass soetwas in deutschland
> illegal ist...
> 
> 
> >5 Jahre sind sehr optimistisch. Eine weltweite Durchsetzung braucht
> >eine kritische Masse. Ein Henne-Ei-Problem. Siehe IPv6, das ist schon
> >ewig standardisiert, aber der zus??tzliche Nutzen rechtfertigt einfach
> >nicht den Umstellungs-Aufwand, meist nichtmal in gr????eren Firmennetzen.
> 
> yup - leider...
> 
> 
> 
> -- 
> Don't worry be happy ...
> Ciao Frank

> _______________________________________________
> 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-mlists.in-berlin.de
> und trage dich dort bitte aus

-- 
----

Ihno at lst.de

"Never trust a computer you can lift."