[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[luga] Re: SPF



On Mon, 2007-01-15 at 21:33 +0100, Bernd Krumböck wrote:
[...]
> >> noch sind diverse Mailgateways, Appliances etc. fähig überhaupt ein
> >> Login zu überprüfen!
> >
> > Es gibt genug Alternativen, daß man solches Zeug nicht verwenden muß,
> > wenn man nicht will.
> 
> Dies halte ich für ein Gerücht. Aber Du kannst mir gerne den  
> Gegenbeweis antreten.

sendmail, exim, qmail, postfix können es. Es gibt auch kommerzielle
Produkte, die es können.
Voila.

> >> SPF ist zwar ein Schritt in die richtige Richtung, jedoch sehe ich
> >> Zertifikate auf dem weitaus besseren Weg, da diese einen Absender
> >
> > Die 2 Wege schließen sich weder aus noch konkurrenzieren sie sich und
> > man kann sie parallel betreiben. Und der SPF-Ansatz ist weniger auf  
> > den
> > Enduser angewiesen, was ihn mbMn signifikant erfolgversprechender  
> > macht.
> > Nicht daß ich irgendwem persönlich was unterstellen will, aber bei 80%
> > der typischen Enduser ....
> 
> Erfolgversprechend wäre eine Umsetzung welche sich mit allen  
> typischen Lebenslagen eines MTA verträgt. --> dies tut es aus meiner  
> Sicht leider nicht.

Eine typische Lebenslage ist im Moment "Emails von überall nach überall
für jedes From: und Mail-From:" zu verschicken, weil es halt bequem ist
oder ich mir nicht mehr Streß antun will.
Und das zu ändern ist weniger ein technisches als ein
menschlich/organisatorisches Problem.

> Ansonsten bevorzuge auch ich Lösungen welche keine Erfahrung bzw.  
> Wissen beim Benutzer benötigt.

Dann sind wir bei "Port 25 zu, benütz' Port 587 und log Dich ein".
Fertig.

Da muß der Benutzer nicht viel denken, sondern an der richtigen Stelle
die Portnummer ändern und Login+Passwort richtig machen. Und *wenn* ein
Spambot das auch benutzt, dann hat dann irgendwann der Betreiber des
Mailservers der Domain ein Problem (und nicht v.a. der Rest der Welt),
wenn bekannterweise von $IGNORANT_PROVIDER viel Spam kommt.

[...]
> >> eindeutig identifizieren und keine großartigen Änderungen an
> >> vorhandene Strukturen bzw. Protokolle stellen.
> >
> > Ja, ich warte auch schon länger auf den Tag, wo sich die große  
> > Masse der
> > Email-Schreiber hinsetzen, pgp/gpg Doku lieset, sich ein Keypair
> > bastelt, dieses bei CACert oder sonstwo seriös signieren läßt und  
> > dieses
> > so auf Keyserver/Webserver packt, daß ich glauben kann, daß er/sie/es
> > wissen, was sie tun.
> > Dazu fehlt mWn noch eine passende SMTP-(oder sonstwas?)  
> > Erweiterung, daß
> > diese Zertifikate automagisch vom MTA *und* MUA gecheckt werden  
> > können.
> > Damit sehe ich da signifikant größere Hürden wie bei SPF.
> 
> Ein Blick bei A-Trust / OpenSSL wird sicher nicht schaden.

Er wird auch nichts nützen, wenn man man nicht viele weitere Blicke dort
hinein und woanders hin wirft sowie einen Haufen Hirnschmalz investiert.

> Zukünftige Rechnungen bzw. Behördengänge werden nur mehr mit Signatur  
> bzw. Zertifikat als gültig angesehen. --> somit wird es sich  

Was noch überhaupt nichts über die Qualität des Zertifikats bzw. dessen
Erteilung und Verwaltung aussagt.

> hoffentlich langsam durchsetzten.

What for?
Oder glaubst Du, daß $GROSSER_PROVIDER irgendwann "Email verschicken nur
mit eingesteckter Keycard" durchsetzen will?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010