[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


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

Re: [luga] Re: SPF





LDAP, Active Directory, Novell Directory, SQL, finger, Perl-Scripts,
Python-Scripts, REXX-Scripts, ...

"Zur Not" muß die vorgeschaltete Appliance per SMTP live checken, ob der
Mailserver hinten die Mail überhaupt annimmmt (im MIMEDefang ist z.B.
eine fix fertige Funktion drin, die das macht) - das mußt eh schon
längst bei jedem Relaying machen, sonst liegen an sich unzustellbare
Mails (idR zu >99% Spams und Backscatter) in der Mailqueue der Appliance
(das mag ja vielleicht sogar an sich nichts tragisches sein - weil die
eh irgendwann irgendwie verschwinden -, aber die andere Seite hat *ihre*
Spammail angebracht. Wenn die Appliance die Mail schon verweigert, muß
sich der drum kümmern, wo sie herkommt.).
Und dazu brauch ich im flexibelsten Fall genau ein Hakerl - jenes, daß
den Check aktiviert und auf der Appliance mußt du genau nichts
konfigurieren, weil durch Mailrelaying der Kiste klar sein muß, wohin
die Mail weiter geht.

Ein Konzern in einer halbwegs mittleren größe für Europa ist in 10 Ländern tätig und hat ungefähr 20 Exchange + 20 Unix Mailserver mit ca. 15 Domains am Laufen. Hier kommt man mit einem Hackerl nicht weit. Egal ob hier eine Appliance oder ein Mailcluster als Gateway fungiert.

Oder was von den genannten Beispielen lässt sich mal schnell für eine heterogene Umgebung als allgemeine Authentifizierungsdienst nutzen. -- > das hört sich immer nur in der Theorie so Klasse an. --> wir tüfteln daran schon seit Jahren

Speziell in der Praxis muß die UNIX Umgebung einen Grad an Verfügbarkeit bieten und kann daher nicht von einem Windows AD abhängen, welcher diese Verfügbarkeit nicht garantieren kann.


Im Prinzip gleich wie zum Lesen der Mails. Da muss sich der User ja auch
authentifizieren.

Yup.

Sorry, aber bitte werft jetzt nicht SMTP mit POP3, IMAP, etc... in das selbe Boot!


Bei einem typisch heterogenen Netzwerk ist das absolut nicht einfach.

Natürlich ist das nicht "einfach" - in heterogenen Netzwerken ist wenig "einfach". Dazu sind wir hier schon konzeptionell ein Ebene höher - bei "welche User hab ich, welche Benutzer hab ich und wie organisier ich wer
wo was darf oder nicht darf". Das hat eine Policy (egal, so sie vorher
schriftlich niedergeschrieben wurde oder im Laufe der Zeit durch "so woa des imma schon" entstanden ist) und die wird dann im Feld gelebt. Und da
ist Email nur eines von mehreren Items (auch wenn es vielleicht das
auffälligste und heikelste ist), wo man das Konzept "Benutzer" hat. Und damit muß man das nicht für eine Spamfilter-Appliance überlegen sondern - in extremen Fällen - für verschiedene Server verschiedener Hersteller
und Services (mehrere DB-Systeme für mehrere Applikationen,
Homedirectory, Email, Webspacezuständigkeiten, etc.).
Und wenn die Lösung ist: Es gibt ein Master-Spreadsheet, wo das alles
drin steht und daraus mehrere
verschiedene /etc/passwd, /etc/shadow, /etc/group,
/etc/gshadow generieren und verteilen  ist, dann kann es nicht der
Mörderaufwand sein, da das n+1. File zu erzeugen und geeignet zu
verteilen, daß halt die Spam-Appliance versteht.

Ich sag nur der alte Traum von SingleSignOn.   :(


Im schlimmsten Fall muss man den Mail-Account halt händisch anlegen.

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

Das ist deren Problem und Fehler.
Das kann auch nicht schlaue Lösungen inhaltlich invalidieren, nur weil
eine Organisation (egal ob es ge.com oder die UNO ist) nicht Willens
oder fähig ist, sie umzusetzen.

So etwas lässt sich durchaus durchführen. Aber dafür braucht man schon mal ein paar 100k Euro, welche nur bei entsprechender Begründung locker gemacht werden. Die Erweiterung eines Mailservice ist hier sicher kein stichhaltiges Argument. --> außer man verdient sein Geld durch den Mailversand, oder kann durch den Umbau langfristig Geld sparen.


Größere Konzerne haben das Problem üblicherweise schon gelöst, und sei
es nur dadurch, dass sie irgendwelche "Enterprise"-Mailsoftware
verwenden, die sowieso Benutzer authentifizert.

Und/oder fette kommerzielle Spam/Viren-filtermaschinerien, weil eh
ausreichend Budget dahinter ist. Aber auch dort gibt es eine
konzernweite Policy ...

Gößere Konzerne haben meist ein internes Kommunikationsproblem und schweben bei manchen Themen über 15 Jahre hinter der aktuellen Technik hinterher. Budget gibt es hier übrigens nur für Dinge welche man unbedingt benötigt. --> das fängt an beim jährlich geplanten IT Budget und endet im blinden Aktionismus.

Sorry, für meine deutlich zu spürende Resignation. --> aber bei diesen Dingen bin ich von der Technik und vom Großunternehmertum in unseren Breitengraden bereits etliche male enttäuscht worden.

Die bisherigen Lösungen funktionieren alle nicht gut genug, um diese ohne weiteres implementieren zu können.

mfg
Bernd





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