Hallo,
Ich könnte einen ganzen Haufen Gründe nennen, weshalb man
einen Mailserver eher nicht unter Windows aufseten möchte
Könntest du - rein interessenshalber - etwas _präziser_ auf
diese Gründe eingehen? Nur ein paar würden mir schon reichen
… Vorraussetzung: den Mailserver (z.B. Exchange 2003) setzt
ein Administrator mit Ahnung auf einem 2003er-Server auf -
Kosten sind hierbei irrelevant …
Naja, wenn die Kosten egal sind, würde ich in der Tat bevorzugen, daß ein Exchange-Admin den Raffel macht und ich mich mit dem größeren Teil des Geldes im sonnigen Süden amüsiere.
Ansonsten: Unix-Mailsever sind erstaunlich weit „fire and forget“: die letzte Sicherheitslücke an qmail ist keine Ahnung wie alt, das Ding ist so sicher wie kaum was.
Zudem laufen die Dinger auf betagter Hardware (Klar, wenn Kosten egal sind, kann ich für den Kaninchenzüchtervorstand auch richtig Hardware springen lassen, aber wer will das schon, wenn er darauf verzichten kann). Auch auf mickrigen Kisten kann man unter Unix ganz, ganz gewaltigen Durchsatz erzielen.
Unix-Mailserver sind exterm modular, ich kann mir aus Einzelteilen das heraussuchen, was für meinen Anwendungszweck optimal ist.
Machen wir das Beispiel bei qmail:
-
man kann wählen, wie man den SMTP-Dienst startet: Ich persönlich bevorzuge tcpserver, aber möglicherweise will man auch couriertcpd, da kann man Optionen für verbindungen noch feiner steuern. Die Lösung über inetd halte ich für ziemlich miserabel, weil man da mit hoher connection rate ein echtes Problem bekommen kann.
-
Man hat die Wahl, alle möglichen Programme zwichen tcpserver und qmail-smtpd einzubauen. Oder anzuhängen. Man kann auf diesem Wege sehr flexibel auhtentifizierungsmethoden einbauen - auch selbstgebaute, sofern nötig.
-
Die Konfiguration von qmail ist simpel und in Textdateien. Sowas transferiert man per Copy&:stuck_out_tongue_winking_eye:aste von einer auf die andere Kiste (und tauscht – so nötig – veränderliche Parameter automatisiert per „grep“ aus"
-
qmail bietet die totale Freiheit, was man mit seinen Mails macht. Auslieferung geschieht in etablierte und stabileDateiformate wie „mailbox“ oder „Maildir“, wobei letzteres extrem genial ist, wenn mehrere Frontend-Maschinen (SMTP, IMAP, POP, Webmail) auf einen gemeinsamen Storage zugreifen, aber nicht nur dann ist es genial. Unter qmail hat man eine seltene Entscheidungsfreiheit, was man sonst so mit den Mails machen kann: sie werden nicht einfach nur dumpf ins Verzeichnis gekippt, sondern man kann sie automatisiert durch alle möglichen Programme schleusen: maildrop, procmail, spamassassin seinen hier genannt. Das Beste: es ist möglich, Domains komplett an einen nichtprivilegierten User zu geben. Oder - wenn nicht mehrere Domains zur verfügung stehen - kann man dem User ansonsten Adressräume zum eigenen gebrauch überlassen.
-
Die Formate, in denen die Mail gespeichert wird , sind gut dokumentiert und portabel.
-
zu qmail gibt es den genialstem Mailinglisten-Manager: ezmlm(-idx). qmail hat einen einen standardkonformen Autoresponder (ja, das ist nicht selbstverständlich)
-
wenn man die Mails nun hat, kann man weiter auswählen, womit man sie ausliefern und zur Verfügung stellen möchte: mit einem der vielenfrei erhältlichen POP3-Server? Courier-IMAP als Server mit POP3, IMAP und jeweils den SSL-Varienten?
-
Du hast einen Server, der kein SSL spricht? Dann hängst Du per tcpserver einen ssltunnel vor. Auch kein Problem.
-
Die Fehlermeldungen, die ich teilweise von Exchange bekommen habe, lassen oft keinen sinnvollen Rückschluß darüber aus, welche Mail-Adresse denn nun betroffen war, einen sinnvolle und hilfreichen Fehlertext habe ich dann lieber nicht mehr erwartet …
-
Wohin geloggt wird, ist frei konfigurierbar. Logdateien können mit den gängigen Tools problemlos weiterverarbeitet werden.
Kurzum: neben dem Kostenargument und dem Performance-Argument sehe ich deutliche Vorzüge in Stabilität, Flexibilität und Wartung.
Vor solchen Tips kann ich nur dringend abraten. Sendmail hat
seine Verdienste, mittlerweile gibt es aber nur Spezialfälle,
wo man über den Einsatz von Sendmail nachdenken sollte.
Ansonsten: Finger weg.
Ich staunte nicht schlecht, als ich per
Quick&Dirty-Programmierung aus einer Datenbank heraus im
Sendmail herumpfuschen konnte, ohne mich auch nur irgendwie
identifizieren zu müssen (z.b. Mails mit nicht existierendem
Absender verschicken)
Das ist – wie mein Vorredner schon zu Recht bemerkte – keine Schwachstelle von Sendmail, sondern eine im Design von SMTP.
… sicherlich lag es auch daran, daß
ein Dummy den Server aufsetzte …
Auwei: Sendmail und Dummy ist eine böse Kombination. Von Sendmail würde ich die Finger lassen, auch wenn ich denke, nich generell mit Mailservern auszukennen. Det is mir zu krautich.
Aber es gibt ja Alternativen, qmail und Postfix exsitieren und spielen Windows-Produkte locker an die Wand…
Gruß,
Sebastian
