[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


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

Re: [luga] Re: SPF




Am 16.01.2007 um 11:06 schrieb Bernd Petrovitsch:

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.

Du hast das falsch verstanden. --> Wie zum Geier bindest Du das Ding mit den Benutzerdaten zusammen?
Bei einem typisch heterogenen Netzwerk ist das absolut nicht einfach.

Bei größeren Konzernen kann das sogar teilweise unmöglich sein, da es eventuell keinen Länderübergreifende Authentifizierung gibt.


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.

Leider ist keine Lösung ohne Vor- und Nachteile.   :(


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.

Das ganze kann ich aber zumindest über einen Filter im MTA bewerten lassen.
Zertifizierungsstelle: Good/Bad
Signatur bereits bekannt: Ja/Nein
etc...


hoffentlich langsam durchsetzten.

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

Nein, aber ein größerer Teil der Benutzer im Geschäftsleben wird eventuell zu diesem Mittel greifen. Wer seine Identität beweisen kann, wird eben einfacher durchgelassen. :)

Ist zwar auch kein Allheilmittel, jedoch wird es die false positive Rate bei wirklich wichtigen Emails senken.

mfg
Bernd


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