Dass der Computeralltag auch unter Linux des Öfteren für Überraschungen gut ist, ist eher eine Binsenweisheit: Immer wieder funktionieren Dinge nicht oder nicht so, wie eigentlich angenommen. Das Answer-Girl im LinuxUser zeigt, wie man mit solchen Problemchen elegant fertig wird.
Es mag in der Windows-Welt noch so unüblich sein, dass ein Heim- oder Arbeitsplatz-PC mit einem eigenen Mailserver ausgestattet ist – bei Linuxinstallationen gehört der SMTP-Server (auch MTA – “Mail Transfer Agent” – genannt) aus gutem Grund zur Basisausstattung. Ohne ihn sähen zum Beispiel Programme wie der Cron-Dämon, der die automatische Abarbeitung bestimmter Aufgaben zu festgelegten Zeiten steuert, recht alt aus, da sie Fehler- wie Erfolgsmeldungen gern per Mail an die zuständige lokale Benutzerin verschicken.
Auch wenn man sonst als Heimanwenderin aus Sicherheitsgründen möglichst alle Internetserver abschaltet (Dienste, die der eigene Rechner nicht anbietet, können auch nicht von Netzbösewichtern missbraucht oder angegriffen werden) – warum sollte man sich mit dem ohnehin sinnvollen lokalen SMTP-Server nicht gleich beim Mailversenden vom Provider unabhängig machen?
Es muss nicht immer Sendmail sein
Vorinstalliert ist bei vielen Distributionen der Großvater unter den MTAs, Sendmail. Dieses Programm ist zwar sehr mächtig, hat aber einen großen Nachteil: Seine Konfigurationsdatei, /etc/sendmail.cf, ist so geschrieben, dass sie von Maschinen leicht, von Menschen hingegen nur schwer gelesen (und verstanden) wird.
Zwar kann man bei den heute verbreiteten Versionen eine leichter verständliche sendmail.mc-Datei erstellen und diese mit dem m4-Präprozessor in eine passende sendmail.cf umschreiben lassen, doch Hand auf’s Herz: Trauen Sie sich zu, ein Programm richtig und sicher zu konfigurieren, dessen Versionsnummer Sie nicht etwa mit sendmail -v oder sendmail --version, sondern lediglich mit
[trish@pc44-148 software]$ /usr/sbin/sendmail -d0 -bt < /dev/null
heraus finden können?
Viele Probleme mit Sendmail treten nur deshalb auf, weil selbst einigermaßen bewanderte Unix-Nutzer/innen nicht die Energie haben, vielhundertseitige Dokumentationswälzer von Vorn bis Hinten durch zu ackern. Dies hat allerdings dazu geführt, dass das Aufsetzen eines eigenen Mailservers als nur von Gurus beherrschbar gilt.
Alternativen wie Sand am Meer
Dem muss nicht so sein, denn zum Glück stört solcherart Benutzerfeindlichkeit selbst die Gurus, die dann eben mal einen eigenen Mailserver schreiben. So hat man mittlerweile die Wahl zwischen den unterschiedlichsten Sendmail-Alternativen – vom “kleinen” smail angefangen über Postfix, Exim, den speziell für stark benutzte Mailserver optimierten Zmailer bis hin zum recht gewöhnungsbedürftigen Qmail. Alle sind gegenüber Anwendungen, die mit Sendmail rechnen, in gewisser Weise flexibel: So findet sich aus Kompatibilitätsgründen immer ein symbolischer Link mit Namen /usr/sbin/sendmail.
Für die Heimbenutzerin spielt optimales Verhalten des MTAs unter großer Last – ein K.O.-Kriterium für Internet-Service-Provider, Universitäten oder große Firmen – keine Rolle. Hier stehen vernünftige Dokumentation und vergleichsweise einfache Installation und Konfiguration im Vordergrund. Alle drei Kriterien zusammen werden meiner Erfahrung nach von Postfix (http://www.informatik.uni-bonn.de/pub/software/postfix/start.html) am besten abgedeckt. Zudem besticht er durch ein vernünftiges Sicherheitskonzept.
Wie wird man Sendmail los?
Daneben hat Postfix den Vorteil, dass er vielen Distributionen als rpm oder deb-Archiv beiliegt oder zumindest als solches erhältlich ist. Red-Hat-Nutzer/innen finden das Paket zwar nicht in der Core-Distribution, dafür aber in den Powertools (zum Beispiel unter ftp://ftp.redhat.com/pub/redhat/powertools/6.2/i386/i386/).
Da sich eine ganze Reihe Programme vom Paketmanager nur dann problemlos installieren lassen, wenn der auch um die Existenz eines MTAs weiß, ist es für einigermaßen harmonieliebende Menschen beinahe zwingend notwendig, auch den SMTP-Server unter Obhut des Paketmanagers zu installieren. Sonst sind rpm oder dpkg an Bockigkeit fast nicht zu überbieten.
Genau mit diesem Problem haben wir auch zu kämpfen, wenn wir Sendmail ersetzen wollen. Einfaches Installieren (-i) des Postfix-Pakets als root funktioniert erstmal nicht:
[root@pc44-148 software]# rpm -ivh postfix-19991231_pl02-4.i386.rpm
error: failed dependencies:
sendmail conflicts with postfix-19991231_pl02-4
Die vorsorglich mit auf den Weg gegebene Option -h (wie “hash”, womit die #-Zeichen gemeint sind, die den Statusbalken einer somit eingeschalteten Fortschrittsanzeige bilden) kommt gar nicht erst zum Tragen, da sich rpm schlichtweg weigert, ein Paket einzuspielen, dessen Abhängigkeiten nicht erfüllt sind. Dank -v (“verbose” – “geschwätzig”) erfahren wir immerhin in aller Ausführlichkeit, dass Sendmail und Postfix einander ausschließen.
Na gut, dann deinstallieren (-e wie “erase”) wir das sendmail-Paket halt…
[root@pc44-148 software]# rpm -e sendmail
error: removing these packages would break dependencies:
smtpdaemon is needed by fetchmail-5.3.1-1
smtpdaemon is needed by mutt-1.0.1i-6
smtpdaemon is needed by nmh-1.0.3-6x
… oder auch nicht: Die installierten Mailprogramme mutt und nmh sowie der “(POP-)Mailabholer” fetchmail wollen ihren SMTP-Server partout nicht hergeben. Ohne ihn wäre ihre Funktionalität eingeschränkt, und da sie ja nicht wissen, dass wir ihnen sofort einen neuen Mailserver an die Hand geben wollen, stellt sich rpm quer.
Doch wir wären nicht Herrin unseres Rechners, wenn wir nicht trotzdem irgendwie aus dieser Zwickmühle heraus kämen. Die rpm-Manpage ist da trotz aller Komplexität recht hilfreich: Mit der Option --nodeps (“no dependencies”) gibt man dem Paketmanager zu verstehen, dass er Abhängigkeiten einfach übersehen soll.
Vorsicht ist allerdings die Mutter der Porzellankiste: Kommt nach dem Einspielen von Postfix überhaupt wieder alles in Ordnung für unsere sendmail-liebenden Mailhelfer? Fragen (“query”: -q) wir doch einfach das Postfix-rpm-Paket (-p wie “packet”), was es denn eigentlich zur Verfügung stellt (--provides).
[trish@pc44-148 software]$ rpm -qp --provides postfix-19991231_pl02-4.i386.rpm MTA smtpd smtpdaemon
Die Antwort lässt uns den folgenschweren Schritt der Sendmail-Deinstallation ruhig angehen: Der von mutt, fetchmail und nmh angemahnte smtpdaemon kommt mit der Postfix-Installation tatsächlich wieder ins Haus.
Also wagen wir uns ins nunmehr nicht mehr ganz so Ungewisse:
[root@pc44-148 software]# rpm -e --nodeps sendmail [root@pc44-148 software]# rpm -ivh postfix-19991231_pl02-4.i386.rpm postfix ################################################## postfix-script: warning: creating missing Postfix pid directory postfix-script: warning: creating missing Postfix incoming directory[...] postfix-script: warning: creating missing Postfix private directory
rpm meckert nicht mehr, dass wir mit dem Löschen (-e) Paketabhängigkeiten zerstören, und mit deinstalliertem sendmail sehen wir auch etwas vom Fortschrittsbalken (-h). Dank eingeschalteter Geschwätzigkeit (-v) erfahren wir von rpm, dass beim Einspielen des postfix-Pakets ein paar vorher noch nicht vorhandene Verzeichnisse (“directories“) namens pid, incoming usw. angelegt wurden.
Gnadenlose Deinstallation mit Debians
apt-get
oder
dpkg
Auch der Debian-Paketmanager meckert natürlich, wenn man ihm dringend gebrauchte Pakete mit -r oder --remove unter dem Hintern wegziehen will:
lillegroenn:/home/trish/docs# dpkg -r sendmail dpkg: dependency problems prevent removal of sendmail: mutt depends on mail-transport-agent; however: Package mail-transport-agent is not installed. Package sendmail which provides mail-transport-agent is to be removed.[...] anacron depends on exim | mail-transport-agent; however: Package exim is not installed. Package mail-transport-agent is not installed. Package sendmail which provides mail-transport-agent is to be removed.[...] dpkg: error processing sendmail (--remove): dependency problems - not removing Errors were encountered while processing: sendmail
Doch dank der --force-Option ist auch dem beizukommen. --force selbst kennt, wie man von dpkg --force-help erfährt, jede Menge Feintuningsoptionen, zum Beispiel
depends [!] Turn all dependency problems into warnings
Alle Abhängigkeitsprobleme in simple Warnungen umwandeln? Das sieht in diesem Fall ganz nach unserem Geschmack aus. Wer doch noch ein wenig Herzklopfen vor dem alles entscheidenen dpkg -r --force-depends sendmail hat, kann zunächst erst einmal einen Trockenlauf (--no-act) starten, bei dem nichts Ernsthaftes passiert:
lillegroenn:/home/trish/docs# dpkg --no-act -r --force-depends sendmail
Nach der langen Warnliste erklärt uns dpkg dann mit einem lapidaren
Would remove or purge zmailer ...
, dass es uns – wenngleich widerstrebend – den Platz für die Postfixinstallation mit dpkg -i postfix_0.0.19991231pl05-2_i386.deb oder apt-get install postfix frei macht.
Selbstverständlich lässt sich auch apt-get zum Entfernen (remove) des störrischen sendmails benutzen:
lillegroenn:/home/trish# apt-get --no-act remove sendmail Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: anacron mailx mutt sendmail 0 packages upgraded, 0 newly installed, 4 to remove and 16 not upgraded. Remv anacron Remv mailx Remv mutt Remv sendmail
Wie zu sehen, löst dies das Abhängigkeitsproblem auf eigene Art: Es entfernt all die Pakete, die einer sauberen Deinstallation im Wege wären, gleich mit.
Solange es im Hause bleibt…
Auch wenn man sich aus guten Gründen noch nicht gleich in die weite Welt hinaus trauen sollte – in der Regel können sich schon jetzt die lokalen Benutzer/innen gegenseitig Mails zuschieben. Wirklich so einfach? Mit einem
[trish@pc44-148 software]$ telnet localhost smtp telnet: Unable to connect to remote host: Connection refused
prüfen wir, ob auf dem SMTP-Port unseres lokalen Rechners (“localhost“) tatsächlich ein Mailserver lauscht. Verbindung verweigert – Pech gehabt! Keine Antwort vom Mailserver und damit auch keine Chance, das kleinste Bisschen Mail zu versenden.
Ehe Sie zu schimpfen beginnen, sollten Sie sich aber vor Augen führen, dass die Anforderungen an Mailserver so vielfältig sind, dass die meisten Administrator(inn)en ganz schön fluchen würden, liefe plötzlich nach der Installation ein Mailserver, der im schlimmsten Fall alles anders macht, als er es sollte: Falsch konfigurierte Mailsysteme können viel Ärger nach sich ziehen.
Solange Sie auf Ihrem Ein-Personen-Rechner sicher sind, dass niemand außer Ihnen Mail verschickt, dürfen Sie es allerdings schon riskieren, die mitgelieferte Konfiguration zumindest für lokale Mail einmal auszutesten.
Wie bei allen Servern, die beim Booten gestartet werden und dann ohne großes Tamtam im Hintergrund laufen (“Dämonen“), findet sich auch für Postfix eine Start-Stop-Datei im Verzeichnis init.d (“Initialisierung von Dämonen”), das sich je nach Distribution unterhalb von /etc, /etc/rc.d, /sbin o.ä befindet. (Exotendistributionen wie Slackware, die dieses praktische System-V-Init-Konzept nicht benutzen, bespreche ich an dieser Stelle ausdrücklich nicht.)
Wechselt man mit cd in dieses Verzeichnis, so reicht ein /postfix start, um einem telnet localhost smtp bei sinnvoller Vorkonfiguration ein Bereitzeichen zu entlocken:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 rechnername ESMTP Postfix
Wenn ich ein Mailprogramm wär’
Wer jetzt schon immer mal wissen wollte, wie sich Mailprogramm (alias “Mail User Agent” – MUA) und SMTP-Server unterhalten, gibt an dieser Stelle den Befehl help ein, worauf Postfix mit einem
502 Error: command not implemented
reagiert. Schade, das hätten wir vorher machen sollen, als uns noch Sendmail zur Verfügung stand. Der hätte nämlich eine wunderbare Hilfe abgegeben, wie man sich mit ihm unterhalten kann:
help 214-This is Sendmail version 8.9.3 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP
". 214-To report bugs in the implementation send email to 214- sendmail-bugs@sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info
Darf die Erklärung der einzelnen SMTP-Befehle (“Topics“) ein wenig detaillierter ausfallen? Bitte sehr:
help MAIL 214-MAIL FROM:
[
] 214- Specifies the sender. Parameters are ESMTP extensions. 214- See "HELP DSN" for details. 214 End of HELP info
MAIL ist also das Kommando zum Angeben des Absenders und RCPT…
help RCPT 214-RCPT TO:
[
] 214- Specifies the recipient. Can be used any number of times. 214- Parameters are ESMTP extensions. See "HELP DSN" for details. 214 End of HELP info
… spezifiziert die Empfängerin.
Doch statt dieser freundlichen Erläuterungen von Sendmail schweigt Postfix an dieser Stelle. Sein Autor, Wietse Venema, geht davon aus, dass die, die wissen, wie man sich mit einem SMTP-Server unterhält, es ohnehin schon können, während er kleine Möchtegern-Spammer nicht mit einer netten Onlinehilfe ermuntern will.
Wir wollen allerdings weder gefälschte Mails in die Gegend hinaus pusten, sondern lediglich unser eigenes System testen, indem wir Mail von (“from“) uns an (“to“) den lokalen Empfänger (“recipient“) ihrbenutzername senden. Wer genau hinschaut, erkennt mit From: ihrbenutzername@ihre.mailadresse in
MAIL From: ihrbenutzername@ihre.mailadresse 250 Ok
die Mail-Absenderzeile und in
RCPT To: ihrusername 250 Ok
die Empfänger-Zeile einer Mail wieder. Mit
DATA 354 End data with <CR><LF>.<CR><LF>
leiten Sie den restlichen Mailtext ein…
testmail
…, den Sie mit einem einzelnen Punkt auf weiter Flur resp. Zeile beenden – ganz, wie es die nette Hilfestellung 354 Schließe die Daten mit Enter-Punkt-Enter ab vorgibt.
250 Ok: queued as BD7F34EC9
Damit wäre die Mail abgeliefert, und wir können uns mit
quit
verabschieden.
Ist die Mail bei Ihnen (resp. ihrusername) angekommen? Um das heraus zu finden, ist es bei der Standardkonfiguration Ihres Mailservers wichtig, dass Ihr E-Mail-Programm die Datei /var/spool/mail/ihrusername als Mailfolder darstellt. Dort landen klassischerweise alle über SMTP eingehenden Mails an ihrusername. Mit Unix-typischen Mailprogrammen wie mutt oder pine dürften Sie hier wenig Probleme haben. Netscape o.a. grafische MUAs hingegen ist nicht immer so einfach davon zu überzeugen, die Mails im Spoolverzeichnis aufzubereiten und ggf. auch dort zu belassen.
Hausmittel
Doch ehe wir uns ganz im Konfigurationswald der MUAs verirren, bleibt uns immer noch der Unixklassiker mail. Wer schon einmal aus Versehen mit diesem Programm zu tun hatte, wird mir vermutlich Recht geben: Als komfortables Alltagsmailprogramm ist es dank seiner etwas “kryptischen” Benutzerschnittstelle nicht zu gebrauchen, doch für unsere Diagnosezwecke reicht es ganz hervorragend.
[trish@pc44-148 software]$ mail Mail version 8.1 6/6/93. Type ? for help. "/var/spool/mail/trish": 1 message 1 new >N 1 trish@regtest.enitel.net Wed Aug 23 20:09 12/371 &
Am mail-Prompt, der hier zur Abwechslung mal & heißt, können Sie sich mit einem Fragezeichen Hilfe holen. Oder eben auch schlicht und einfach eine 1 tippen, um die Mail Nummer 1 zu lesen:
& 1 Message 1: From trish@regtest.enitel.net Wed Aug 23 20:09:09 2000 From: Patricia Jung <trish@regtest.enitel.net> To: trish@regtest.enitel.net Date: Wed, 23 Aug 2000 20:08:46 +0200 testmail &
Sie erkennen Ihre Testmail wieder? Die From:-Zeile entspricht genau dem, was Sie hinter dem MAIL-Kommando getippt haben, die To:-Zeile hingegen dem, was nach dem RCPT kam, ggf. angereichert um den Rechnernamen. Bleibt der Datumsstempel, den der MTA vergeben hat. Doch halt: Da ist ja noch ein zweites From, diesmal ohne Doppelpunkt, das wohl ebenfalls vom Mailserver erzeugt wurde.
Alles äußerst spannend, nur vielleicht interessiert erst einmal, wie man diese Mail Nr. 1 wieder löscht (engl.: “delete”)…
& d1
…, alle restlichen Mails anzeigt…
& h No applicable messages
…, sich damit eine Abfuhr holt, weil die einzige Mail ja schon im Nirwana gelandet ist, und mit “quit” das Programm beendet:
& q
Natürlich lässt sich mail auch zum Testmailschreiben verwenden:
[trish@pc44-148 software]$ mail -v ihrusername Subject: testtestmail 2. Cc:[ Enter-Taste betätigen ]
… und dank des Schwatzhaftigkeitsparameters -v (“verbose”) zeigt uns mail jetzt auch an, wie es die Mail bei Postfix abliefert:
send-mail: open maildrop/56CAC13ABD
Am Rande der Legalität?
Schön wär’s, wenn das alles wäre. Denn ginge es darum, unsere Testmail zu beantworten, so ist deren Absenderadresse (im Beispiel trish@regtest.enitel.net) alles andere als brauchbar; wäre sie so auf einem anderen Rechner angekommen, sogar illegal, denn sie existiert schlichtweg nicht wirklich. Damit fangen unsere Konfigurationsprobleme erst an…
Gerade Privatpersonen haben ihren Rechner selten im DNS eingetragen. So kann sich Postfix bei der Installation keineswegs guten Gewissens den für die Maschine vorkonfigurierten Fully Qualified Domain Name (FQDN) schnappen, um ihn für die Antwortadresse zu verwenden. Jede Mail sollte schließlich so ausgezeichnet werden, dass eine Antwort darauf auch ankommt. Und hier sieht es für nicht im DNS stehende Rechner düster aus.
Zwar lässt sich in guten Mailprogrammen ein Reply-To:–Header festlegen, mit dem man dem Empfänger-Mail-User-Agent erklärt, an welche Adresse er antworten soll. Schlechte Mailprogramme beachten diesen jedoch nicht. Außerdem haben wir damit immer noch keine gültige Absenderadresse und verstoßen so gegen Internetnormen. Vernünftige und nicht zu alte Mailprogramme erlauben es daher, den From:-Absenderheader auf eine gültige Mailadresse zu setzen.
Das würde reichen, wenn wir unsere Mail einfach nur beim Smarthost-SMTP-Server unseres Providers ablieferten. Doch von dem wollen wir ja gerade nicht abhängen, und da stoßen wir auf ein weiteres Problem: Während wir auf den Reply-To:– und den From:-Header ggf. noch mit unserem MUA Einfluss haben, generiert der entgegen nehmende Mailserver, wie wir an der Testmail gesehen haben, eine sogenannte Envelope– (“Briefumschlag”)-Adresse. Der Inhalt dieser From-Zeile (ohne Doppelpunkt) wird von einigen Mailservern auf seine Existenz geprüft, da Spam an dieser Stelle oft eine nicht im DNS nachschlagbare Adresse enthält.
Mit einer solchen, nicht auflösbaren Adresse bringen wir uns in arge Schwierigkeiten: Nicht nur, dass wir bei vielen Mailservern gar keine Mail los werden; einige schicken die darüber informierende Fehlermeldung eben an jene nicht wirklich existierende Adresse, sodass wir die Absage nie erhalten. Wenn Mailpartner wiederholt steif und fest behaupten, Mails nie bekommen zu haben, der Absender sich seinerseits nie an abweisende Post vom gegnerischen Mailerdämon erinnern kann, handelt es sich oft um dieses Szenario.
Adressmanipulation
Also nehmen wir uns schweren Herzens die Postfix-Dokumentation zur Hand. Das Herzstück der Konfiguration ist die Datei main.cf, üblicherweise in /etc/postfix zu finden. Auskunft gibt aber auch der Paketmanager mit rpm -ql postfix | main.cf oder dpkg -S main.cf. (Die rpm-Optionen lassen sich mit -q für “query” – nachfragen und -l für “list(e aller im Paket enthaltenen Dateien)” merken, das -S beim Debian-Paketmanager steht – noch einfacher – für “Suche” oder “Search”.)
Auch wenn es sich lohnt, die zum Beispiel in http://totem.fix.no/postfix/basic.html beschriebene Grundkonfiguration genauer in Augenschein zu nehmen (besonders dann, wenn das Senden der Testmail nicht gelang – siehe auch den Kasten “Nur noch konfigurieren – die wichtigsten Parameter aus main.cf“), interessiert uns vor Allem der Punkt Adress Manipulation (http://totem.fix.no/postfix/rewrite.html) in der Dokumentation.
Was für ein halbkriminelles Wort – und doch die einzige Möglichkeit, als “Internetkrüppel” ohne feste IP-Adresse und DNS-Eintrag einen unbescholtenen Mailserver zu betreiben.
Nur noch konfigurieren – die wichtigsten Parameter aus
main.cf
Zum Glück stehen fast alle Parameter in Postfixens Hauptkonfigurationsdatei auf sinnvollen Defaultwerten. Zudem sind sie – wenngleich auf Englisch – meist recht aussagekräftig dokumentiert. Dennoch sollte man die Konfiguration durchgehen, halbwegs verstehen und ggf. anpassen, bevor man den Server startet.
Wie so oft dient auch in dieser Datei ein # als Kommentarzeichen, das verhindert, dass Postfix den Rest der Zeile ernst nimmt. Ein $ mit einem Variablennamen dahinter bedeutet, dass Postfix statt dieser Kombination den Wert der Variablen “sieht”.
- Wenn Sie ein für Ihre Distribution gefertigtes
rpm– oderdeb-Paket einsetzen, werden die verschiedenen Verzeichnisse (queue_directoryfür die Mailwarteschlange sowiecommand_directoryfür die Postfix-Hilfs- bzw.daemon_directoryfür die nötigen Dienstleistungsprogramme) auf die richtigen Werte gesetzt sein. Im Fehlerfall prüfen Sie, ob diese Verzeichnisse vorhanden und die beiden letzten mit den passenden Programmen gefüllt sind. Wenn Sie jedoch schon an dieser Stelle deutliche Fehlstellen bemerken, die nicht auf bewusste Manipulationen Ihrerseits zurück gehen, sparen Sie sich ggf. eine Menge Ärger, indem Sie mit einem neuen Paket einen neuen Anlauf wagen. mail_owner, die Besitzerin der Mailwarteschlange und der meisten Postfix-Prozesse, sollte keinesfalls aufroot, sondern auf einen speziellen User (beispielsweise ganz langweiligpostfix) gesetzt werden. Sehen Sie in der/etc/passwdnach, dass es diesen auch gibt. Wenn nein, müssen Sie ihn anlegen und ihm ggf. die Rechte am Mailspool und den diversen Postfixprogrammen übertragen.- Bei Abläufen, bei denen Postfix keine speziellen Sonderrechte braucht (wie sie der
mail_owneroder in noch stärkerem Maßerootbesitzen), sollte er diese auch nicht haben. Daher setzt mandefault_privsauf einen möglichst rechtelosen Benutzer wie den meistens vorkonfigurierten Usernobody. - Wenn
myhostnameden FQDN des Rechners enthält, brauchen Sie sich ummydomain(das standardmäßig nur den Domänenbestandteil vonmyhostnameenthält) undmyorigin(normalerweise dasselbe wiemyhostname) nicht weiter kümmern. Den Standardwert erfahren Sie zum Beispiel mit dem Kommandohostname --fqdn. Entspricht dieser Wert nicht Ihren Vorstellungen, ändern Sie den Wert Variablen. Vergessen Sie dabei nicht, das Kommentarzeichen zu entfernen. - Vielleicht ist Ihnen aufgefallen, dass jede Mail einen Header namens
Message-ID:enthält. Diese Kennung besteht aus einer von Ihrem Mailserver generierten eindeutigen Zeichenfolge, einem@und dem Wert vonmyorigin. Da die verschiedenen Mailserver jedoch nichts über die jeweils von anderen generierten Strings wissen, sollte auchmyorigineindeutig für Ihren Rechner stehen, damit keine Dubletten auftreten. Auf den Domainnamen Ihres Providers oder auflocalhostsetzen Siemyorigindaher bitte nicht. - Wenn Sie Ihren Mailserver lediglich zum Versenden von Mail nach außen und für lokale Mail benutzen, nicht aber zum
Empfangenvon Mail aus dem Netz, beschränken Sieinet_interfacesauf$myhostname, localhost. - Endstation (
mydestination) für ankommende Mail ist Ihr Mailserver für Mails, die wahlweise anlocalhost, $myhostnameadressiert sind. - In der Datei
aliasesbestimmen Sie, wer die Post bekommt, die an bestimmte lokale Benutzer geht. Wichtig ist zum Beispiel, dass Sie anrootgerichtete Mail einem tatsächlich maillesenden und verantwortlichen Benutzer (zum Beispiel sich selbst) unterschieben. Sinnvoller Standardwert ist
alias_maps = hash:/etc/postfix/aliases
wobei Sie /etc/postfix/aliases zumindest dahin gehend ändern sollten, dass die Zeile mit root: auf der linken Seite rechts daneben entweder Ihren lokalen Benutzernamen oder eine Ihrer gültigen Mailadressen enthält. Beispiel (zum Anpassen, nicht zum unreflektierten Abschreiben!):
root: pjung@linux-user.de
Sollten Sie sich mit Ihrer alten, aus Sendmail-Zeiten stammenden /etc/aliases unendlich viel Mühe gegeben haben, können Sie diese natürlich in alias_maps recyceln. Vergessen Sie jedoch nicht, die Datei mit dem postalias-Kommando ins angegebene hash-Format umzuwandeln.
- Klassischerweise ist
/var/spool/maildasmail_spool_directoryunter Linux. Mithome_mailboxkönnen Sie lokale Mail aber auch in einer Datei im Homeverzeichnis der Benutzer/innen unterbringen. Das ist zum Beispiel sinnvoll, wenn diese Netscape oder Kmail benutzen. Zeitgenossen, die statt einer Folder-Datei gern jede Mail einzeln als Datei abspeichern, ist mithome_mailboxbeizukommen. Experimentieren Sie hier gern ein wenig, indem Sie Mails an einen lokalen Testbenutzer verschicken (und achten Sie darauf, dass Postfix nach jeder Änderung seine Konfiguration neu einlesen muss). Allen Ihren Nutzer(inne)n Recht tun können Sie es allerdings nicht: Für ein System für alle müssen Sie sich schon entscheiden…
Der Punkt ADDRESS REWRITING in der main.cf hört sich ganz nach dem an, was wir wollen: Absenderadressen umschreiben bzw. maskieren. Ein Blick in die mitgelieferte Beispiel-Konfigurationsdatei sample-canonical.cf (im Postfix-Dokumentationsverzeichnis /usr/doc/postfix-19991216 o.ä.) bestätigt, das wir den richtigen Hebel gefunden haben:
# Der Parameter sender_canonical_maps spezifiziert optionale Tabellen, # in denen nachgeschlagen werden kann, welche Envelope- und Header-Adresse # ein bestimmter Absender bekommen soll. # # Sie benötigen diese zum Beispiel, wenn Sie die Absenderadresse user@ugly.domain # zu user@pretty.domain umschreiben wollen, wobei es weiterhin möglich # sein soll, Mail an die Empfängeradresse user@ugly.domain zu schicken.
Unser Stichwort hier ist Envelope- und Header-Adresse: Mit der “Umschlagsadresse” ist jene doppelpunktlose, oberste From-Zeile im Header einer Mail gemeint, mit “Header-Adresse” die From:-Zeile. Also schreiben wir dem Beispiel in der Dokumentation folgend eine Textdatei namens /etc/postfix/sender_canonical. Darin steht links die Mailadresse, wie sie im aktuellen Zustand automatisch erzeugt wird, wenn eine Benutzerin eine Mail abschickt, rechts, wie die passende gültige Adresse lautet. Die linke Seite können Sie Ihrer Testmail entnehmen. Sie besteht aus dem Benutzernamen auf dem System (also dem Namen, mit dem sich die betreffende Nutzerin einloggt), dem @-Zeichen und dem Inhalt der Konfigurationsvariablen myorigin aus main.cf (siehe Kasten). Ein Beispiel:
trish@regtest.enitel.net pjung@linux-user.de
Damit wird aus der lokalen Benutzerin trish die Absenderin pjung@linux-user.de mit einer gültigen Mailadresse.
Jetzt müssen wir in der main.cf lediglich noch die Variable sender_canonical_maps mit dem Namen unserer Tabellendatei füttern:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
Wie sag’ ich’s meinem Mailserver?
Damit hätten wir alles, was wir brauchen, und dank des Kommandos /usr/sbin/postfix reload brauchen wir Postfix nicht einmal mit ./postfix restart im init.d-Verzeichnis neu starten. Eine neue lokale Testmail verfasst …, nur das, was ankommt, hat immer noch falsche Header (nämlich die “alte” Adresse von der linken Seite):
From trish@regtest.enitel.net Wed Aug 23 21:19:06 2000[...] From: trish@regtest.enitel.net (Patricia Jung)
Was haben wir da falsch gemacht?
Besonders, wenn die Benutzeranzahl eines Mailservers wächst, dauert es viel zu lange, eine ewiglange Textdatei einzulesen. Postfix kennt daher mehrere Formate, in denen es Konvertierungstabellen wie /etc/postfix/sender_canonical einliest. Welche, das verrät laut FAQ (zum Beispiel http://www.postfix.cs.uu.nl/faq.html#intranet) das Kommando
[root@pc44-148 software]# /usr/sbin/postconf -m nis regexp environ btree unix hash
Wir hatten mit dem Präfix hash: in sender_canonical_maps angegeben, das hash-Format zu benutzen. Das bedeutet, dass wir Postfix keine “langsame” Textdatei, sondern ein spezielles Binärformat liefern wollten.
Richtig – bis jetzt haben wir das noch gar nicht getan: Um aus der Textdatei die “Map” zu erzeugen (daher das -m im postconf-Befehl), gibt es einen speziellen Befehl namens /usr/sbin/postmap, dem wir als Argument den Namen unserer sender_canonical-Textdatei mitgeben:
[root@pc44-148 software]# /usr/sbin/postmap /etc/postfix/sender_canonical
Ein ls -al /etc/postfix verrät, dass in diesem Verzeichnis eine neue Datei namens sender_canonical.db generiert wurde. Anschließend – und dafür haben wir hart gearbeitet – klappt’s auch mit der Testmail:
From pjung@linux-user.de Wed Aug 23 22:04:02 2000[...] From: pjung@linux-user.de (Patricia Jung)
Glossar
-
SMTP
-
“Simple Mail Transfer Protocol”, die Vereinbarung, wie E-Mails durchs Internet transportiert werden.
-
Cron-Dämon
-
Als Dämon (von engl. “daemon” – “disk and execution monitor”) bezeichnet man ein Programm, das als dienstbarer Geist ständig im Hintergrund läuft. Der Zeit-Dämon (je nach Distribution cron oder crond) arbeitet in Crontabs (“Cron-Tabellen”) festgelegte Aufträge zum darin spezifizierten Zeitpunkt ab.
-
symbolischer Link
-
Mit dem Kommando ln -s angelegter Verweis auf eine andere Datei. So lässt sich eine Datei unter verschiedenen Namen ansprechen.
-
rpm oder deb
-
Selbstverständlich kann man Open-Source-Software jederzeit selbst kompilieren und installieren. Doch dann muss man auch darauf achten, dass verschiedene Programme nicht miteinander kollidieren, und sich merken, welche Datei man wohin gesteckt hat, um sie später sauber zu deinstallieren. Diese Mühen nehmen einem Paketmanager wie rpm (eingesetzt von Red Hat, Mandrake, Caldera, SuSE u.a.) oder dpkg/apt-get (Debian und Derivate) ab. Im Gegensatz zu Quelltextpaketen lassen sich solche Binärpakete aber meist nur auf dem System installieren, für das sie gedacht sind. rpm-Pakete erkennt man an der Endung .rpm, Debian-Pakete an .deb.
-
Abhängigkeiten
-
(engl.: “dependencies”) Klassische Unix-Mailprogramme setzen voraus, dass sie die mit ihnen fabrizierten E-Mails an einen lokalen Mailserver los werden können – sie sind von ihm derart abhängig, dass ihre Existenz auf einem Rechner ohne MTA nicht gerade sinnvoll ist. Jedes rpm- oder deb-Paket enthält solcherart Information, sodass der Paketmanager die (De-)Installation einer Software verweigern oder zumindest warnen wird, wenn eine Beeinträchtigung der Funktionalität des Gesamtsystems oder einiger seiner Teile zu erwarten steht. Ähnlich wenig sinnvoll ist es, für den Hausgebrauch zwei verschiedene Mailserverprogramme neben einander zu installieren, und sei es nur, weil beide andere Vorstellungen vom jeweils eigenen /usr/sbin/sendmail-Link haben.
-
POP
-
Das “Post Office Protocol” bietet eine Möglichkeit, auch dann Mail zu erhalten, wenn man nicht ständig mit seinem eigenen SMTP-Server online ist. Hier spielt der POP-Server des Providers Postfach und erlaubt der Kundin, die (per SMTP) eingesammelten und zwischengelagerten Mails zu einem späteren Zeitpunkt mit einem passenden Werkzeug (fetchmail) oder einem POP-fähigen Mailprogramm abzuholen.
-
.
-
Ausführbare Dateien in Verzeichnissen, die nicht im Such-Pfad liegen, muss man mit komplettem Pfad aufrufen. Liegt das Programm im aktuellen Verzeichnis, lautet dieser . (“Punkt”). echo $PATH gibt den Such-Pfad aus.
-
Spammer
-
Firma oder Mensch, die/der andere Menschen durch Zusenden unverlangter E-Mailwerbung (“Spam”) belästigt. Da Spammer meist selbst nicht gern eine ebensolche Flut ungehaltener Antwortmails zurück bekommen wollen, fälschen sie Absenderadressen und benutzen fremde Mailserver (“Open Relays”) für ihre Aktivitäten, wenn diese nicht genau darauf achten, von wem sie Mail entgegen nehmen und an wen sie Mails weiter leiten.
-
CR/LF
-
Die guten alten (nach den gleichnamigen Aktionen bei der Schreibmaschine benannten) ASCII-Zeichen Wagenrücklauf (“Carriage Return”) und Zeilenvorschub (“Line Feed”) werden zwar nur unter DOS und Abkömmlingen gleichzeitig durch den Druck auf die Enter-Taste erzeugt, sollen aber in diesem Zusammenhang andeuten, dass man doch bitte Return drücken soll. Unter Unix ist ein harter Zeilenumbruch übrigens nur ein LF (unter MacOS nur ein CR), was zum Beispiel gewisse Editoren unter Windows oder auch Drucker im ASCII-Modus übel nehmen. Daher ist es sogar bei reinen Textdateien wichtig, auf die richtige Kodierung des Zeilenumbruchs zu achten und ggf. Tools wie dos2unix und unix2dos zur Umwandlung zu benutzen.
-
DNS
-
Das “Domain Name System” sorgt als auf viele Maschinen (Nameserver) verteilte Datenbank dafür, dass man Rechner statt über die menschenunfreundlichen numerischen IP-Adressen wie 195.143.20.22 auch über ausgeschriebene textuelle Adressen (“www.linux-magazin.de”), bestehend aus Rechnernamen (“www”), Subdomäne(n) (“linux-magazin”) und Top-Level-Domäne (“de”) ansprechen kann. Im DNS ist zudem eingetragen, welcher Mailserver Mail für eine bestimmte Domäne (zum Beispiel linux-magazin.de) entgegen nimmt.
-
FQDN
-
Der “Fully Qualified Domain Name” eines Rechners besteht aus dem Rechnernamen (zum Beispiel www) und der vollständigen Domäne (linux-magazin.de).
-
Header
-
Eine Mail besteht immer aus zwei Teilen: den Verwaltungsinformationen wie Absender- und Empfängeradresse, Betreff (Subject), Art des Dokuments (MIME-Type) usw. sowie der eigentlichen Nachricht, dem Body. Viele Mailprogramme verstecken die meisten Header vor den Benutzern. Wie man sie komplett angezeigt bekommt, ist vom MUA abhängig. Die meisten Unix-Mailclients speichern die Mails jedoch in ihrer originalen ASCII-Text-Form ab (selbst gif-Bilder oder doc-Dateien werden für den Mailtransport in lauter ASCII-Zeichen umgewandelt und müssen vom Mailprogramm nachher wieder in ihr ursprüngliches Format gebracht werden). Damit kann man sich mit einem einfachen less /var/spool/mail/benutzername (bzw. der passenden Datei(en)) die gesamte Inbox mit den ungeschminkten Headern anschauen.
-
grep
-
Ein Standard-Unix-Kommandozeilenwerkzeug zum Auffinden von Zeichenketten. Schiebt man die Ausgabe eines Befehls (hier von rpm -ql postfix) durch die “Pipe” | “ins grep-Kommando hinein”, so sucht es dort nach dem angegebenen String (hier nach main.cf).
