[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



On Tue, 2007-01-16 at 22:25 +0100, Peter J. Holzer wrote:
> On 2007-01-16 19:47:24 +0100, Bernd Krumböck wrote:
> > 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?

Die Appliance wird das definieren (müssen), ob man dort Listen der
validen Accounts raufladen kann oder sonstige Methoden. Wenn sie halt
nur eine Methode zuläßt und die nur für ein System funktioniert, daß ich
nicht habe (bzw. nicht haben will), dann brauch ich sie nicht weiter zu
berücksichtigen.

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

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

Yup.

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

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

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

	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