server Kompendium

Transkript

1 server Kompendium 17. Juni 2004 Copyright c 2002, 2003, 2004 Roland Huber Es ist erlaubt dieses Dokument unter den Bestimmungen der GNU Free Documentation License, Version 1.2 oder eine spätere Version, die von der Free Software Foundation veröffentlicht wurde, zu kopieren, verteilen und/oder modifizieren; eine Kopie der Lizenz liegt diesem Dokument in Anhang A bei. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". 1

2 Danksagung Dieses Danksagung habe ich aus aktuellem Anlass abgeändert, da verschiedene Dokumentationen der Linux-Tin Gruppe unter der GFDL bei diversen Unternehmen mit gefälschtem Copyright aufgetaucht sind. Ich möchte hier darauf hinweisen, dass ab Version diese Lizenz bindend ist. Eine Zuwiderhandlung kann und wird unserem Rechtsbeistand übergeben. (Liebe Kollegen und im speziellen... liebe Schulungsunternehmen, was habt ihr davon, wenn ihr diese Dokumentation auf euren Webseiten veröffentlicht mit eigenem Copyright? Es ist doch frei und sollte den GNU Vermerk tragen! Ich habe einige dutzend Stunden daran gearbeitet und Geld investiert, ohne dafür etwas zu verlangen, außer, dass die GFDL eingehalten wird!) Genug des Zauderns, ich möchte allen Danken, die Verbesserungsvorschläge eingebracht haben oder Kritik. Um diese Dokumentation weiterhin zu pflegen und um Verbesserungen bzw. Änderungen dieser Dokumentation verfolgen zu können, bitte ich jeden Leser darum, diese an die -adresse: zu senden. Roland Huber 2

3 Teil I: Cyrus, Postfix, Fetchmail Inhaltsverzeichnis 1 Grundsätzliches Vorwort Begriffserklärungen Grafische Darstellung server - Typische Teile eines servers Was macht der MTA Was macht ein MUA Lange Einleitung und kein Ende Vorbereitungen Analyse Phase 1: Server Hardware Analyse Phase 2: Server Software Postfix - der MTA Postfix im Überblick Das Konzept hinter Postfix Möglichkeiten die Postfix bietet Konfiguration des Postfix Servers Konfigurationsdatei master.cf Konfigurationsverzeichnisse / -dateien des Servers Konfigurationsdatei main.cf Adressen richtig umsetzen: die canonical Tabelle: Systemaccount s: die aliases - Tabelle SMTP Rechte? Die access - Tabelle Postfix (neu) starten Postfix testen Abschließende Bemerkung Cyrus IMAP Server Cyrus im Überblick Das Konzept hinter Cyrus IMAP Möglichkeiten, die Cyrus bietet Konfiguration des Cyrus Servers Konfigurationsdatei cyrus.conf Konfigurationsdateien des Servers Konfigurationsdatei /etc/imapd.conf Cyrus IMAP testen Administration von Cyrus Anlegen von Benutzern Löschen von Benutzern ACLs - Zugriffskontrolle auf Mailboxen Einzelnen Benutzern Rechte gewähren Gruppe von Benutzern Rechte gewähren Quota - Festlegen von Mailboxgrößen Bulletin Boards und Shared Folders Einrichten eines Shared Folders (Offener Ordner): Einrichten eines Bulletin Boards:

4 5 SASL, PAM und Authentifizierung SASL oder auch Cyrus SASL SMTP-Authentifizierung unter Postfix Cyradm und SASL PAM Fetchmail Grundsätzliches zu Fetchmail Konfiguration Fetchmail manuell starten

5 1 Grundsätzliches 1.1 Vorwort Selbst lese ich eher selten irgendwelche Vorworte die ja nur Zeit kosten. Deshalb gehe ich auch nicht wirklich davon aus, dass dieses hier besonderen Anklang findet. Kurz umrissen erkläre ich hier auch nur, wie es zu dieser Dokumentation kam. Als ich vor einiger Zeit begann den eigenen server zu konstruieren, wusste ich noch nicht, dass dies mein Projekt mit größtem Umfang werden würde. Mir schwebte vor, die volle Funktionsvielfalt eines - Servers àla Microsoft Exchange bzw. Lotus Notes nachzubilden (nicht die komplette Groupware Funktionalität zwar, jedoch große Teile des Spektrums rund um die ). Zugrundeliegende Methoden und Protokolle sollten bei meinem Server einem allgemeingültigen Standard entsprechen. Letztendlich landete ich bei all diesen Anforderungen bei IMAP und SMTP. Die Informationssammlung stellte mich auf eine harte Probe. Beginnend beim MTA Sendmail stellte ich schnell fest, dass die per-hand Konfiguration und Administration zu aufwendig werden würde. Über kurz oder lang landete ich (neben einigen Ausflügen zu QMail oder Exim) bei Postfix. Keine Frage, für meinen Kenntnisstand und Ziel gab es keine bessere Lösung. Dies jedoch ist reine Geschmacksache. Alle MTAs sind standardisiert und spielen hervorragend mit den anderen Komponenten zusammen; hier in dieser Anleitung wird jedoch immer nur Bezug auf Postfix als MTA genommen. Die restlichen Teile des Mailservers, wie Cyrus IMAP und Fetchmail gesellten sich erst nach einer Weile hinzu, die ich ihnen aber hier nicht vorenthalten möchte und werde. Mein Versprechen, dieses Vorwort nicht zu sehr in die Länge zu ziehen, möchte ich jetzt einlösen und mit einem abschließenden Dankeschön an Mark Tominski zum Hauptteil übergehen. 1.2 Begriffserklärungen MTA: Mail Transfer Agent. Das Bindeglied aller Komponenten eines Mailsystems. Der MTA übergibt s an andere MTAs oder liefert sie an lokale MDAs aus. Er nimmt s von wieder anderen MTAs entgegen bzw. erhält sie über weitere Zwischensysteme (z.b. Fetchmail). Postfix und Sendmail sind bekannte Vertreter dieser Gattung. Siehe dazu die Abbildung auf der nächsten Seite. Einen MTA können sie sich als Postamt vorstellen, welches Briefträgern oder Verwalltungsangestellten Richtlinien vorgibt, was in welcher Form zu tun ist. MDA: Mail Delivery Agent: Übernimmt die s vom MTA und verteilt diese an den entsprechenden Benutzer - schiebt diese in Warteschlangen oder übergibt sie an Programme, die diese Mails weiterverarbeiten. Procmail oder Deliver sind MDAs. Bildlich können sie sich den MDA als Postboten vorstellen, der anhand der Anschrift und Postleitzahl weiß, wohin der Brief zugstellt werden soll - in ein Postfach, oder an eine bestimmte Adresse. MUA: Mail User Agent. In der elektronischen Welt ist dies der - Client. In der realen Welt können sie den MUA mit dem Briefeschreiber/-empfänger oder Postkasten vergleichen. POP3: Post Office Protocol. Dieses sehr weit verbreitete Protokoll erlaubt einem Client- Computer abzuholen und auf dem Rechner zu speichern und zu verwalten. 5

6 Eine Verwaltung auf dem Server ist äußerst eingeschränkt und eigentlich nicht vorgesehen. Ein Vergleich mit der realen Welt kommt das Protokoll dem einfachen Postschliessfach nahe. Jede neue Post wird einfach eins nach dem anderen hineingeworfen und kann je nach Wunsch abgeholt werden. IMAP4: Internet Message Access Protocol. Umfassendes Protokoll, in dem die serverseitige Verwaltung von s beschrieben ist. Es gibt drei Möglichkeiten der Mailverwaltung: online, offline oder verbindungsorientiert. Dieses Protokoll mit der Realität zu vergleichen ist schon ein bisschen schwerer. Ich vergleiche es dennoch gerne mit einer(m) Sekretär(in), welche(r) die Post vorsortiert und in Ordner packt, vorlegt und später dann weiterverwaltet. SMTP: Simple Mail Transport Protocol: Ein Server zu Server oder Client zu Server Protokoll - so tauschen MTAs Nachrichten aus bzw. so senden Clients ihre Mails direkt an einen zentralen MTA. 1.3 Grafische Darstellung Hier möchte ich die zuvor vorgstellte Thematik noch einmal in eine grafische Form bringen server - Typische Teile eines servers In der folgenden Grafik sieht man sehr gut, aus welchen Teilen ein Mailserver besteht. Für alle Teile gibt es eine Unmenge an verschiedenen (OpenSource) Produkten, dennoch harmonieren alle Teile auf Grund der offenen Standards hervorragend miteinander. 6

7 1.3.2 Was macht der MTA Das untenstehende Bild zeigt die Funktionsweise eines MTAs. Ich stelle hier sowohl eine externe wie auch eine interne vor, bzw. deren Wege. Die interne Adresse wird durch den MTA als solche erkannt und in den MailStore (lokale ablage) weitergegeben (z.b. /var/spool/mail). Die s an die externe Adresse kann nicht in den lokalen Speicher geschrieben werden, deswegen wird diese (evtl. über einen Zwischenhost) an den externen MTA übergeben. In den Begriffen realen Post, wird einmal der Brief an das Postamt ausgeliefert, das dem Empfänger am nächsten ist und dann von dort zugestellt. Das andere Mal ist der Empfänger im selben Postleitzahlengebiet wie das Postamt - der Brief kann direkt zugestellt werden ohne eine zentrale Sortierstelle zu bemühen Was macht ein MUA Im nächsten Bild sieht man die zwei möglichen User Agents. Ein IMAP Client tauscht (im Online-Modus) während der Bearbeitung ständig Daten aus. Dabei wird im Normalfall oder Idealfall pro Client ein Serverprozeß gestartet. Im realen Leben kann man sich den Datenaustausch als ein Gespräch zwischen Verwaltungsangestellten vorstellen, die aushandeln, wohin z.b. die einzelnen Briefe sortiert werden sollen. 7

8 1.4 Lange Einleitung und kein Ende... Das war mal wieder eine lange Einleitung, aber um unseren server erfolgreich implementieren zu können sind obige Grundbegriffe essentiell. Im nächsten Abschnitt geht es um die Vorbereitungen. Das hier vorgstellte System ist sehr genügsam, dennoch darf man nicht unterschätzen, was ein IMAP-Mailserver alles leisten muss, besonders bei steigender Benutzerzahl. 8

9 2 Vorbereitungen 2.1 Analyse Phase 1: Server Hardware Gehört dieser Punkt eigentlich in diese Anleitung? Mit der Version wollte ich diesen Punkt eigentlich streichen, aber da kaum jemand glaubt, wie genügsam ein gut konfigurierter IMAP-Mailserver sein kann im Vergleich zu vielen kommerziellen System, habe ich diesen Punkt dahingehend überarbeitet. Leider ist jedoch eine π mal Daumen - Rechnung oder eine allgemeine Aussage nicht möglich. Alles hängt immer vom Mailverhalten der User und dem zur Verfügung stehenden Budget ab. Es gibt Firmenkulturen, die das interne Mailsystem auch als Filesharing-Tool einsetzen; die Möglichkeit IMAP Mailboxen für ganze Gruppen zugänglich zu machen und hierarchisch nach Sender, Empfänger, Zeitstempel etc. zu sortieren mag verlockend wirken, bin selbst aber kein Fan davon. Große Datenmengen müssen übertragen und gespeichert werden - der Server hat also jede Menge zu tun. Da ich keine Möglichkeit habe Tests mit größerem Umfang in meinem Minilabor aufzubauen, beschränken ich mich in dieser Dokumentation auf eine Useranzahl von maximal 100 Clients, obwohl ich schon Server mit 5000 und mehr Benutzer und einer ähnlichen zugrundeliegenden Konfiguration administriert habe. Für gewöhnlich sollten sie pro User 200 MB Festplattenplatz veranschlagen. Die IMAP - Mailbox zusammen mit den LOG-Files usw. liegen zwar oftmals darunter, aber etwas Luft zum Atmen sollte unser System noch haben. Zudem setzte ich 4 MB Hauptspeicher pro User an. Daten werden in den Puffer geschrieben und der IMAP Server arbeitet effizienter. Nehmen wir also an, ihr geplantes Ziel ist ein Server mit maximal 100 Usern. Für diese sollte dann ein Plattenplatz von MB = 20000MB 20GB bereitgestellt werden. Aus Erfahrungsgründen ist auf Grund von Wartbarkeit und bei einem Datengau (Recovery der vorhandenen Daten in ein zweites Verzeichnis) eine Verdopplung des Plattenplatzes durchaus zu empfehlen und MB = 40000MB 40GB bereitzustellen. Diese stellen den optimalen Ausbau dar; bei heutigen Plattenpreisen klingt das immer noch lächerlich. Zurück zum Hauptspeicher MB = 400MB für den server sollte es schon sein - mehr ist dann nur noch Luxus :-). Da das Betriebssystem auch noch gerne ein wenig Hauptspeicher und Plattenplatz für sich hätte, geben wir diesem luxuriöse 100 MB RAM und 20 GB Fesplattenplatz. Fassen wir zusammen: ca. 60 GB Festplattenplatz und 512MB RAM für 100 User macht schon Freude. Die Frage der CPU erübrigt sich in diesen modernen Zeiten. Die billigste aktuelle Prozessorgeneration ist ausreichend. Selbst ein Uraltsystem der Pentium I Reihe (ia32) und 200MHz könnte das Mailaufkommen bewältigen, obwohl ich bei hochfrequentierten Systemen und einigen hundert offenen IMAP Threads schon Wartezeiten auf einem Dual Xeon System erlebt habe. Dies ist jedoch zu 99% ein Problem der Clientsoftware im Zusammenspiel mit schlechter Administration - sprich: keine gesetzten Quotas bei denen dutzende von Benutzern meherere Gigabyte große Mailarchive ihr eigen nannten. Nicht zu verschweigen sei, dass auch andere Architekturen gut geeignet sind (z.b. von mir getestet auf PPC604/200MHz unter SuSE 7.1 PPC) Zurück zum Thema: obige Rechnung ist also nur ein Anhaltspunkt und die Minimalausstattung - bei entsprechendem Budget ist selbstredend ein redundantes Serversystem neuester Generation zu bevorzugen. Wie kommt man zu den Zahlen? Eine Umfrage unter großen Betreibern von Cyrus- IMAP Servern zeigt, dass ein IMAP System mit etwa 1 bis 2 MB Hauptspeicher pro 9

10 aktiven IMAP-Prozess ausgestattet sein muss. Pro User werden im Schnitt nicht mehr als zwei Prozesse gestartet. Dadurch kommt man auf die Zahl 4 MB. Plant man einen server, spielen neben den Ressourcen vorallem auch Ausfallsicherheit und Verfügbarkeit eine große Rolle. Dies würde jetzt aber zu weit führen und überlasse es den Hardwareherstellern. 2.2 Analyse Phase 2: Server Software Das Betriebssystem GNU/Linux stellt eine sehr gute Basis für einen erfolgreichen Mailserver dar. Bei Mehrprozessorsystemen sollte man mindestens Kernel 2.4.x heranziehen, welcher vornehmlich seit sehr zu empfehlen ist. Für diesen Artikel wählte ich die Distribution SuSE 9.0 Pro. Natürlich sind auch andere Derivate von Debian bis RedHat geeignet sowie UN*X Abkömmlinge von FreeBSD bis Darwin. Im Folgenden gebe ich kurz jene Pakete an, die ich speziell für das server Projekt nachinstalliert habe (+ bedeutet hinzugefügt und - entfernt): Network/Server [+] Expirienced User [+] Simple Webserver with Apache [+] cyrus-imapd / cyrus-sasl-* [+] MySQL-Max und Client-Tools [+] imap [-] Einige Pakete werden nicht direkt benötigt, unter SuSE ist dies jedoch die einfachste Methode das System funktionstüchtig aufzusetzen. Falls sie ein anderes System einsetzen, achten sie bitte darauf, folgende Programmpakete auszuwählen, bevor sie beim nächsten Punkt fortfahren: Postfix, Fetchmail, Cyrus-Imapd und Cyrus-Sasl. Diese Pakete mögen wiederum abhängig von einigen Bibliotheken sein. Der genaue Installationsweg über den Sourcecode ist bei den Paketen zu finden, bei den Distributionen über den jeweiligen Paketmanager. Keine Angst - die Installation gestalltet fast immer sehr problemlos. 10

11 3 Postfix - der MTA 3.1 Postfix im Überblick Bei Postfix handelt es sich um einen flexiblen, einfach zu konfigurierenden, modularen und sicheren MTA Das Konzept hinter Postfix Durch seinen, im Gegensatz zu Sendmail, konsequent modularen Aufbau ist es der Mail Transfer Agent meiner Wahl und kann ihnen deshalb diesen nur ans Herz legen. Natürlich würde der hier vorgestellte Mailserver auch mit Sendmail zusammenarbeiten, ist dann jedoch wesentlich schwerer zu konfigurieren und zu verwalten. Modularer Aufbau bedeutet, dass es sich nicht um ein einzelnes monolithisches Programm handelt sondern aus vielen Teilen besteht. Diese Teile wiederum können unterschiedliche Rechte besitzen und müssen nicht als Superuser root laufen. Welche Teile dies sind, möchte ich ihnen in folgender Tabelle vorstellen: Modul master qmgr nqmgr pickup postdrop smtp smtpd bounce cleanup local pipe showq trivial-rewrite Erklärung Wie der Kernel von Linux handelt es sich bei master um den Koordinator des Zusammenspiels der übrigen Module Queue-Manager, also die Verwaltungseinheit von Postfix (alte Version) New Queue-Manager, also die neue und verbsserte Version von qmgr. Kümmert sich um die Warteschlange und den -Versand Zuständig für die Aufnahme neuer s aus der Queue und Weitergabe an cleanup Nimmt lokal erzeugte s entgegen und speichert diese in der Queue Zuständig für den Versand an andere Mailserver via smtp Der Gegensatz von smtp. Nimmt also s entgegen, die von anderen Hosts stammen Zuständig für unzustellbare s Sollte eine Mail im Header unvollständig sein, ergänzt dieses Modul fehlende Einträge leitet s an lokale Mailboxen weiter Kann weitere externe Module zwischenschalten Anzeige der Queue und Status der enthaltenen s Verändert bzw. fügt evtl. fehlende Einträge in Headern von Nachrichten hinzu Möglichkeiten die Postfix bietet Wo soll ich da anfangen? Unter diesem Punkt könnte man getrost einen Roman schreiben? Nicht nötig! Postfix bietet genau die Möglichkeiten, die man von einem MTA erwartet. Sogar noch etwas mehr! Zufrieden mit dieser Aussage? Ich denke nicht, deshalb nun eine Zusammenfassung. Eingehende s werden entgegengenommen und an die entsprechenden Ziele verteilt bzw. als Relay-Server zwischengelagert. Zugegeben - Postfix kann schon noch ein bißchen mehr, aber beschränken sie sich zunächst auf diese Möglichkeiten. 11

12 3.2 Konfiguration des Postfix Servers Postfix hat an die 100 Konfigurationsparameter die in der Datei.../postfix/main.cf 1 zusammengefasst sind. Dennoch sind die meisten Parameter mit guten Defaultwerten vorbelegt. Es reicht also in den meisten Fällen aus, einige wenige Änderungen vorzunehmen. Besonderes Augenmerk sollten sie auf das Verzeichnis.../postfix 2 legen. Hier liegen i.d.r. die Konfigurationsdateien mit deren Hilfe sie alle Einstellungen rund um den MTA vornehmen können Konfigurationsdatei master.cf Bei der master.cf handelt es sich um die Konfigurationsdatei, die den Koordinator postmaster beschreibt. Hier wird definiert, welche Teile wie zu agieren haben. Wenn sie sich diese Datei genauer ansehen, erkennen sie einzelne Module und deren Aufrufe. Der folgende Ausschnitt zeigt die Datei in ihrem Urzustand: # ======================================================================== # service type private unpriv chroot wakeup maxproc command + args # ======================================================================== smtp inet n - n - - smtpd pickup fifo n n n 60 1 pickup cleanup unix - - n - 0 cleanup qmgr fifo n - n qmgr cyrus unix - n n - - pipe flags=r user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -m ${extension} ${user} Unter normalen Umständen muss an dieser Datei nie etwas geändert werden. Eine Ausnahme werden sie jedoch im zweiten Teil des Kompendiums kennenlernen Konfigurationsverzeichnisse / -dateien des Servers Im Folgenden werde ich die einzelnen Dateien und Pfade kurz vorstellen wie sie i.d.r. vorgegeben sind. Der aufgeführte Pfad kann je nach eingesetztem System variieren - in der Regel handelt es sich jedoch um den dargestellten. /etc/postfix/main.cf: 90% von Postfix werden in dieser Datei konfiguriert. Hier werden all jene Einstellungen festgelegt, die zur grundsätzlichen Funktion notwendig sind. Sobald der server korrekt arbeitet, werden sie nur noch selten über diese Datei stolpern. /etc/postfix/master.cf: Diese Datei hatten wir schon mal :-). Eigentlich sollte sie nur in Ausnahmefällen und Spezialanwendungen verändert werden. /etc/postfix/access: Konfiguration rund um eingehende s. Sie werden hier anhand des Mailheaders auf ihre Rechtmäßigkeit eingestellt. /etc/aliases: Anhand des Alias werden lokale s anderen Adressen zugeordnet. Weshalb dies notwendig ist, erkläre ich weiter unten. 1 Der volle Pfad lautet i.d.r. /etc/postfix/main.cf 2 Bei vielen Distributionen gilt hier /etc/postfix 12

13 /etc/postfix/canonical: Um eine reibungslose Funktion zu gewährleisten kann es notwendig sein, smtp-header und smtp-envelope zu verändern bzw. anzupassen. Welche Gründe es dafür gibt, erfahren sie weiter unten. /etc/postfix/relocated: Muss eine Adresse zurückgewiesen werden, weil der tatsächliche Empfänger nicht mehr unter dem alten Namen existiert, aber die neue Adresse bekanng ist, wird hier ein Eintrag vorgenommen. /etc/postfix/transport: Normalerweise ist das Protokoll SMTP der Standard zum versenden von s. Muss aber ein anderes Protokoll verwendet werden, z.b. UUCP, kann dies hier zusätzlich konfiguriert werden. /etc/postfix/virtual: Diese Datei ist vergleichbar mit /etc/aliases. Bietet zusätztlich erweiterte Funktionalität (z.b. externe Weiterleitung) Konfigurationsdatei main.cf Diese Konfigurationsdatei kann in manchen Distributionen auch mit Hilfe einer grafischen Oberfläche verändert werden. Meiner Meinung nach sollten sie dies jedoch tunlichst unterlassen, da sie auf etwaige Seiteneffekte keinen Einfluss mehr haben. Wesentlich mehr Möglichkeiten Postfix zu steuern, haben sie, wenn sie die Datei mit einem Texteditor bearbeiten - außerdem können sie nur so die tatsächliche Funktionsweise eines MTAs erlernen. Die wichtigsten Variablen stelle ich ihnen nun kommentiert vor. Lesen sie sich die Anleitung einfach durch - auf eine vollständige Datei komme ich im Anschluß zurück... Los gehts... zunächst geben sie den ISP Mailserver oder Masterserver an, der die zu versendenden Mails entgegennimmt. Statt dem Domänennamen könnte hier z.b. auch die IP-Adresse stehen: relayhost = smtp.linux-tin.org Wollen sie s in der Warteschlange nur zu bestimmten Zeiten an den Hauptserver weiterleiten, können sie die sofortige Weitergabe unterbinden mit Angabe der folgenden Variable (weglassen bedeutet sofortiges versenden): defer_transports = smtp 13

14 Der nächste Abschnitt behandelt die Grundeinstellungen von Postfix. Besonderes Augenmerk gilt der hervorgehobenen Zeile, die speziell für den Cyrus IMAP Server eingetragen sein muss. Dabei handelt es sich um den MDA, der die Mails lokal an den IMAP Server verteilt (Die Verzeichnisse müssen selbstredend an ihr gewähltes Betriebssystem angepasst werden). program_directory = /usr/lib/postfix command_directory = /usr/sbin daemon_directory = /usr/lib/postfix queue_directory = /var/spool/postfix mailq_path = /usr/bin/mailq default_privs = nobody mail_spool_directory = /var/mail mailbox_command = /usr/lib/cyrus/bin/deliver mailbox_transport = cyrus fallback_transport = cyrus local_destination_concurrency_limit = 2 default_destination_concurrency_limit = 10 default_peer_level = 2 Es folgt die IP-Range des Netzwerkes in dem sich die Clients befinden. Die hier eingetragenen IP-Adressen gelten als trusted also vertrauenswürdig. Nur den hier angegebenen IP-Adressen ist es erlaubt auch s nach außen - sprich ins Internet zu senden: mynetworks = /24, /8 Darstellung des Hostsnames des Mailservers (+ Domäne) nach dem Schema: mailservername.localdomain.cc. Dieser Eintrag hat zunächst keine direkte Bedeutung. Um eine Absenderadresse zu bilden, zieht Postfix den Eintrag aus $mydomain heran. myhostname = mail.linux-tin.org mydomain = linux-tin.org myorigin = $mydomain Der nachfolgende Eintrag weist dem Benutzer postfix die Rechte der Prozesse rund um den Dienst zu. Dies wird benutzt um einen Angreifer keine Möglichkeiten zu bieten, ausserhalb des Postfixprozesses schaden anzurichten. mail_owner = postfix Das Standardprotokoll für Postfix wird mit dem nächsten Eintrag geregelt. Hier: SMTP. default_transport = smtp Jetzt könnte hier eine lange Geschichte über den richtigen Absender bzw. Adressaten stehen. Nur kurz: weder gehört es zur Netiquette, noch ist es besonders sinnvoll NICHT- Offizielle Domänennamen als From: - Adressaten zu verwenden. (Besonders dann, wenn eine Antwort auf s erwartet wird). Deswegen ist eine Maskierung mit einer offiziellen Adresse notwendig. Hier nur der Eintrag, dass du eine Maskierung durchgeführt werden soll, mehr zu diesem Thema weiter unten. canonical_maps = hash:/etc/postfix/canonical Das SMTP-Banner legt den Begrüßungstext fest, den der smtp - Daemon an die anderen Mailserver überträgt. Grundsätzlich sollte man nicht zuviel von sich verraten, also 14

15 keinesfalls das verwendete Betriebssystem etc. preisgeben. Hier die Zeile für den Hostnamen und den Protokolltyp: smtpd_banner = $myhostname ESMTP Als nächstes die Angabe, wo sich Alias-Einträge befinden. alias_maps = hash:/etc/aliases Die Gruppenidentifikation und den User-Relay setzt man hiermit fest: setgid_group = maildrop luser_relay = $root@mail.linux-tin.org Sofern man sich gegen einen externen SMTP - Server authentifizieren muß sind nachfolgende Zeilen notwendig. Eine Erklärung folgt später nach der Grundkonfiguration in Kapitel 5: smtp_sasl_auth_enable = yes smtp_sasl_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/sasl_password Adressen richtig umsetzen: die canonical Tabelle: Mit Hilfe der canonical-tabelle kann man Empfänger- und Absenderadressen austauschen. Dies wird in einigen Umgebungen benötigt, die intern mehrere Domänen besitzen, sich nach außen jedoch nur mit einer domäne zu erkennen geben wollen. Umgebungen, die intern unschöne, technisch bedingte Benutzernamen vergeben - nach außen jedoch mit einer gefälligeren Adresse arbeiten wollen benutzen dieses System um etwa rhuberu17@internal.cc der Adresse roland.huber@linux-tin.org zuzuordnen. Sofern eine interne, und inoffizielle Domäne maskiert werden soll um einen externen provider zu emulieren ist canonical ebenfalls die beste Wahl. Mit Hilfe der canonical-tabelle wird nicht nur den Austausch im SMTP-Envelope 3 durchgeführt sondern auch im Mailheader. Die Adressen werden demnach völlig transparent angepasst. Für den Empfänger sieht es also aus, als ob die von einem offiziellen Mailserveraccount aus gesendet worden wäre. Um es kurz und schmerzlos zu machen - spätestens wenn die interne Domäne nicht die selbe ist, wie die adresse sollte die canonical Tabelle zum Einsatz kommen. Hier ein Beispiel, wie sie einige Usernamen umsetzen können: casper@internalname.cc peter@foobar.org Ungünstig übrigens ist es, wenn sie ihren internen Benutzername z.b. auf name@localhost umleiten, denn damit erzeugen sie eine fatale Mailschleife. Gern genommen wird auch die Umleitung von name@localhost auf name@externeadresse.org. Damit würden alle auflaufenden s direkt zurück an den externen Mailserver geleitet. Sie sollten also die Umleitungen stets nach obigem Beispiel anwenden. Ist die canonical - Datei erstellt, muss diese noch in das Bekeley Datenbankformat umgewandelt werden mit dem Befehl: linux: # postmap /etc/postfix/canonical 3 Der SMTP-Envelope ist vergleichbar mit einem Briefumschlag, auf dem u.a. der Absender und Empfänger steht. Mailserver betrachten nur diesen Umschlag um s zuzustellen und nicht den Inhalt der . Wichtig ist, dass der Envelope nicht gleichzusetzen ist mit dem -header. 15

16 Im entsprechenden Verzeichnis entsteht dadurch neben der Datei canonical auch noch eine canonical.db Systemaccount s: die aliases - Tabelle Aliases sind Umleitungsanweisungen für lokale adressen. Historisch bedingt liegt diese nicht innerhalb des Konfigurationsverzeichnises von Postfix (meist /etc/postfix), sondern direkt unter /etc. Im Grunde ist die von Postfix eingeführte virtual - Tabelle eine Erweiterung von /etc/aliases, dennoch benutzen eine Vielzahl von Programmen diese noch heute. Deswegen sollten sie diese auch benutzen, obschon die virtual - Tabelle weit umfangreichere Möglichkeiten bietet. Aliases werden zumeist eingesetzt um Systemaccounts auf einzelne Benutzeraccounts umzubiegen. Beispielsweise, um Systemnachrichten an root in eine Benutzermailbox umzuleiten. In der Datei /etc/aliases sind bereits einige Standard-Aliases vorgegeben. Diese Datei müssen sie nur noch für den eigenen Gebrauch anpassen. So leite ich z.b. alle root - Mails direkt in den Account roland@linux-tin.org. Die Datei erklärt sich sehr gut von selbst, weswegen ich sie hier nicht komplett angebe. Sehen sie sich diese an und verändern sie die entsprechenden Aliases nach eigenem Gebrauch. Anmerkung: Unter Postfix muss der Account root unbedingt einem eingetragenen User zugewiesen werden, der alle System- s empfängt, da Postfix als nicht priveligiertes Programm läuft und auf keine Dateien des Benutzers root zugreifen darf. postmaster: root MAILER-DAEMON: postmaster root: roland roland: roland@linux-tin.org Nachdem sie die Datei gespeichert haben, benutzen sie das Kommando newaliases um die Hash-Tabelle aliases.db zu erstellen SMTP Rechte? Die access - Tabelle Die Datei.../postfix/access ist optional und regelt, ob einzelne Adressen, oder ganze Domänen zum Empfang freigegeben sind oder blockiert werden. Man kann hier nur angeben, ob s angenommen oder zurückgewiesen werden. Z.B. lässt sich durch den folgenden Eintrag ein Spamer REJECT Falls sie mit dieser Datei weitere Einschränkungen treffen wollen, wird eine Menge Information in.../postfix/access selbst geboten. Zum vernünftigen Kampf dem Spam ist dies jedoch so nicht geeignet. Eine zweckmäßige Spam - Abwehr stelle ich im zweiten Teil dieses Kompendiums vor. Übrigens: Nach dem Anpassen der Datei müssen sie eine Berkely-Database aus ihr generieren mit dem Befehl: linux: # postmap /etc/postfix/access 16