Klarstellung:
MTAs (Mail-Transfer-Agents) sind die Programme,
die Mails entgegennehmen und entscheiden, an welchen anderen Rechner
sie weitergeleitet werden müssen oder ob die lokal zugestellt
werden sollen.
Diese lokale Zustellung inklusive des Formats (mbox oder
maildir) ist ausschließlich Sache der MDAs,
der Mail-Delivery-Agents.
(Diese Seite wurde im Januar 2004 begonnen. Sie will und kann auf die nächsten Monate keinen Anspruch auf Vollständigkeit erheben.)
Bzgl. der verschiedenen MTAs herrschen diverse Vorurteile. Z. B. ist sendmail unsicher, die Konfigurationsdatei nicht zu verstehen, es sind zu viele Konfigurationsdateien ... Und überhaupt ist sowieso alles andere sicherer, besser und einfacher zu verstehen.
Lassen wir das erstmal so stehen ...
Derartige Allrounder sind heutzutage ausgesprochen sparsam gesät. Aber nur eine Handvoll Vokabeln auswendig lernen und dann sendmail komplett umkrempeln können, das wird nicht klappen!
Immerhin ist es seit der Überarbeitung in den 80er Jahren für den durchschnittlichen Betreiber eines Mail-Servers nicht mehr notwendig sich mit zugegebenermaßen kryptischen* Datei sendmail.cf herumzuschlagen. Statt dessen sind für veschiedene Grundfunktionalitäten vorbereitete mc-Dateien vorgegeben, die nur noch mittels Makro-Aufrufe an die lokalen Gegebenheiten (Domain, abweichende lokale Dateinamen usw.) angepaßt werden müssen. Natürlich, wenn ich ein Haar in der Suppe suche, ist mir das auch schon zu kompliziert!
(* Die sendmail.cf-Datei sieht deshalb so kryptisch aus, weil Eric Allman damals den Parser für die Konfigurationsdatei wahrscheinlich selber schreiben mußte. Einstellige Makro-Namen (oder Variablen-Namen) machen das Leben dabei sehr viel einfacher. Insbesondere, wenn das eigentliche Problem nicht ein "schönes" Sprachdesign, sondern die Inbetriebnahme eines MTAs ist.)
Zu mehr bin ich bei diesem Mailer noch nicht gekommen.
Nochmal zurück zu den Vorurteilen:
Was mir immer um die Ohren gehauen wird, ist die Behauptung, daß (de facto) alle anderen MTAs einfacher als sendmail zu konfigurieren seien. Zu dieser Erkenntnis kommen die Leute üblicherweise, nachdem sie in die sendmail.cf (in der die Leute absolut nichts verloren haben!) reingeschaut und nichts verstanden haben, weil sie sich vorher in keiner Weise in Bezug auf die Vokabeln schlau gemacht haben. In den Konfigurationsdateien der anderen MTAs finden sich dann lesbare Vokabeln wie z. B. sender_canonical_maps; hat zwar auch keiner eine Ahnung, was man damit machen kann, aber es suggeriert, daß man's verstehen kann.
Auch immer wieder beliebt: "Ich hab" den MTA XY auf meinem
Rechner installiert und schon nach einem halben Tag konnte ich
Mails verschicken und empfangen."
Klasse! Bloß, wenn ich den Konfigurationsaufwand für das popelige
Mail-aus-Rechner-raus-und-in-Rechner-rein in Verhältnis zu dem
halben Tag setze, wird die Konfiguration für einen unserer
zentralen Mailer dieses Jahr nicht mehr fertig.
(Ich schreibe das hier übrigens gerade am 18. Januar.)
Die Anzahl der Konfigurationsdateien wird auch immer gern ins Feld
geführt. Erst neulich mal wieder einer: das seien bei
sendmail ja so fürchterlich viele und die ganzen
Kommandos, die man anwerfen müsse, newaliases
und makemap. (Hätte ich ihm verraten sollen,
daß newaliases auch nur einen makemap-Aufruf
macht??) Bei postfix stünde das alles in einer Datei.
???
Dann frage ich mich nur, wieso auf meinem Testrechner ein Katalog
/etc/postfix mit einem ganzen Stall voll Dateien existiert.
Und wenn in der "einen" Konfigurationsdatei dann etwas von
"... hash:<andere_Datei>" drinsteht, hat sich das mit
"einer Datei" ja ganz offensichtlich erledigt ...
Nichts dagegen, daß anderen Admins der eine oder andere MTA mehr entgegenkommt und deren Bedürfnisse schon in der Standard-Konfiguration erfüllt. Aber an die Konfiguration eines Mailers für 100 Benutzer werden deutlich weniger Anforderungen gestellt als bei einen Mailer für >20.000 Benutzer.
Nochmal wegen der Anzahl der Konfigurationsdateien: Es ist durchaus sinnvoll nicht alles in einer Datei zu versenken, denn bei Änderungen müßte der Mailer jedes Mal neu gestartet werden (oder auch nur getreten die geänderte Konfiguration neu zu lesen). Darüber hinaus kann es ab einer gewissen Menge an Daten einfach effizienter sein Teile der Konfigurationsdaten erst dann zu holen, wenn sie wirklich gebraucht werden. Oder umgekehrt: sie gar nicht zu lesen, wenn sie nicht gebraucht werden. In dieser Beziehung werden sich wahrscheinlich alle MTAs änlich verhalten.
| Feature | sendmail | postfix | exim | qmail |
|---|---|---|---|---|
| Mailer nur auf bestimmten IP Mails akzeptieren lassen | DAEMON_OPTIONS(`Addr=<IP>,...') | inet_interfaces = <IPs> | ||
| Mail auf anderem als Standard-Port(25) Mails empfangen lassen | DAEMON_OPTIONS(`...,Port=<Zahl>,...') | (nicht inet_interfaces) | ||
| Relay, bei dem Mails abgeliefert werden sollen | define(`SMART_HOST', `smtp:<Host>') | relayhost = <Host> | ||
| Nicht-Standard-Port(25) auf Relay | in Mailer-Definition: A=TCP <Port> | relayhost = <Host>:<Port> | ||
| virtuelle Mail-Adressen |
Die auf diesen Seiten zum Ausdruck gebrachten Meinungen sind die meinigen, nicht notwendigerweise die der Universität Osnabrück. (Es sei denn, sie würden zufällig übereinstimmen oder wären entsprechend gekennzeichnet.)
Zum Thema "Links":
Bei "Links" handelt es sich stets um "lebende" (dynamische) Verweisungen. Gernot Skalla hat bei der erstmaligen Verknüpfung zwar den fremden Inhalt daraufhin überprüft, ob durch ihn eine mögliche zivilrechtliche oder strafrechtliche Verantwortlichkeit ausgelöst wird. Er überprüft aber die Inhalte, auf die er in seinem Angebot verweist, nicht ständig auf Veränderungen, die eine Verantwortlichkeit neu begründen könnten. Wenn er feststellt oder von anderen darauf hingewiesen wird, daß ein konkretes Angebot, zu dem er einen Link bereitgestellt hat, eine zivil- oder strafrechtliche Verantwortlichkeit auslöst, wird er den Verweis auf dieses Angebot aufheben.
(Quelle: Impressum/Disclaimer des Berliner Beauftragten für Datenschutz und Informationsfreiheit Stand: 09/2002)
Last change: Sun Jan 18 17:47:21 NFT 2004