[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


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

Re: [luga] Re: SPF



On Wed, 2007-01-17 at 19:29 +0100, Bernd Krumböck wrote:
[...]

Du hast grade das Thema gewechselt, aber was solls:

> 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.

Das ist aber alles nicht unser Problem oder Aufgabe sondern deren
"freie" Entscheidung. Und damit dürfen die es auch lösen.
Und die haben auch viele Leute in der IT-Administration - wenn die nur
am Helpdesk sitzen, kann ich ihnen auch nicht helfen. Wenn die nicht
wissen, wohin sie wollen, detto.

> Oder was von den genannten Beispielen lässt sich mal schnell für eine  
> heterogene Umgebung als allgemeine Authentifizierungsdienst nutzen. -- 

Wenn du die IT an die Umgebung anpaßt (oder umgekehrt oder irgendwo in
der Mitte die 2 sich treffen): Die allermeisten (wenn nicht alle).
Wenn du ein Plug-n-Play Lösung suchst: Keine, weil Du ein
organisatorisches Problem technisch lösen willst. Und funktioniert mEn
nur in Ausnahmefällen.

Und sobald "mehrere Standorte" mitspielen, ist die erste Frage: Wie sind
die vernetzt und wer ist wo wofür zuständig und darf entscheiden?
Und bevor die Fragen nicht vollständig und korrekt beantwortet sind,
brauch' ich über eine organisatorische Lösung gar nicht nachdenken (ganz
zu schwiegen von der konkreten technischen Umsetzung derselben).

>  > 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.

Dann muß eine andere Lösung her und Win-AD fliegt raus oder wird von
extern befüllt (wenn man Samba als PDC und BDC nicht benützen kann oder
will) - was auch immer einfacher, leichter oder politisch opportuner
ist.

> >> 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!

Warum?
Weil wir sonst eine Lösung hätten?

> >>> 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.   :(

Traum? Ich hab das (ja, inkl. Windows-Domäne).
Ist nur eine Frage der Organisation.

> >> 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  

Cool, wo darf ich Angebote schreiben?
Und kannst Du die Grundlagen für die Zahl belegen oder soll sie nur
kleine Kinder abschrecken?

> 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.

Wie man das intern "verkauft", muß man sich auch überlegen. Da gleich
eine (fette) Zahl dazuzuschreiben (oder nur eine lange Liste von Risken
und Problemen mitzuliefern) ist mbMn die Art, von unten nach oben "ich
will das nicht" zu kommunizieren.

> >> 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  

Ja, die haben auch noch den "Streit" mehrerer Abt. um den eigenen
Erhalt. Stell' Dir vor, das wird alles dermaßen effizient organisiert,
daß ich mit 50% der Leute 150% der Services erhalten kann. Die Leute
unten können gar keine Interesse daran haben, das zu verändern, weil es
sonst ein 50% Chance gibt, daß sie ihren Job los sind oder am Ende gar
was anderes machen müssen und das könnte etwas neues sein.

> 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.

V.a. wenn Showmenschen an den falschen Stellen sitzen. Oder der fachlich
ahnungslose Klischee-Manager zu spät irgendwas (letztendlich
chaotisches) macht und verändert, damit er nachher sagen kann "ich hab
alles versucht und es war nicht behebbar und der Termin doch nicht
haltbar".

> 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.

So what? Ist alles deren Problem, wenn sie halt immer noch sinnlose
Spammails und Backscatter ohne Ende bekommen (und vielleicht sinnlos
viel Geld in den Rachen externer Dienstleister werfen) und nicht meins.

> Die bisherigen Lösungen funktionieren alle nicht gut genug, um diese  
> ohne weiteres implementieren zu können.
   ^^^^^^^^^^^^^
Organisatorische Plug-n-Play-Lösungen gibt es nur, wenn die Organisation
sich ans Tool anpaßt (Hat hier wer "SAP" geflüstert?). Sobald das nicht
der Fall ist, ist das "ohne weiteres" sowieso weg.

	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