Fedora 15
Das eigene E-Mail Archiv mit ArchiveSMTP
Die Rechtslage in Deutschland wird zunehmend unübersichtlicher und bisweilen widersprechen sich einzelne Rechtsvorschriften sogar gänzlich. Der einzelne Bürger weiß dann nicht mehr wie er sich verhalten soll. Egal was er tut, so oder so verstößt er gegen geltendes Recht. So ein Fall sind auch E-Mails, die im Unternehmensbereich geschrieben werden. Einerseits sind solche E-Mails möglicherweise Handelsbriefe im Sinne des HGB für die es zwingende Aufbewahrungspflichten gibt. Andererseits sind solche E-Mails aber vieleicht auch Meinungsäußerungen einzelner Mitarbeiter, die durch deren Persönlichkeitsrechte geschützt sind und eventuell nicht einmal von Anderen als dem Empfänger eingesehen werden, geschweige denn aufbewahrt werden dürfen. Nun könnte man ja sagen, die geschäftlichen E-Mails speichern und die privaten nicht, aber wie wollen Sie denn wissen was geschäftlich und was privat ist, Sie dürfen die E-Mails ja von vorneherein erst gar nicht einsehen, denn sie könnte ja privat sein. Im Vorfeld wissen Sie das aber gar nicht. Glauben Sie mir, ich bin kein dummer Mensch aber trotz intensiver Recherche hat mir bislang keiner sagen können wie man sich verhalten soll. Die einen meinen halt so, die anderen so.
Das Problem
Gott sei Dank interessiert mich diese rechtliche Frage hier aber gar nicht. Ich will nur wissen, was ich technisch tun kann, wenn ich denn - aus welchen Gründen auch immer - alle ausgehenden E-Mails archivieren will.
Früher einmal war ich immer davon ausgegangen, diese Frage sei trivial und man müsse nur einen Konfigurationsparameter ändern und Sendmail würde fortan alle ausgehenden E-Mails speichern. Dem ist aber nicht so. Sendmail ist zu dieser Handlung einfach nicht zu überreden (Möglicherweise befürchten die Sendmail Entwickler ja auch Repressalien wegen der latenten Verletzung von Persönlichkeitsrechten?). Dann fängt man normalerweise an das Internet zu durchforsten. Interessanterweise findet man dort aber keine konstruktiven Lösungsvorschläge für dieses Problem. Wenn dennoch irgendjemand diese Frage in den einschlägigen Foren zu stellen wagt, erntet er nur ellenlange Beschimpfungen. Der arme Fragesteller wird dort regelrecht zum Stasispitzel gebrandmarkt.
Die Möglichkeiten
Nun, ich will nicht lange drum herum reden. Ich kenne zwei gut funktionierende Lösungen, um alle ausgehenden E-Mails zu archivieren. Die eine ist Synonym von Modulo Consulting aus Bukarest in Rumänien, die andere ist ArchiveSMTP von Dancing Fortune Software aus Sidney in Australien. Synonym finden Sie unter dieser URL: http://dv8.ro/Synonym/synonym.html und ArchiveSMTP finden Sie unter jener: http://www.dancingfortune.com/projects/archivesmtp/index.php.
Beide Produkte sind sehr ähnlich. So benutzen beide Sendmails Milter Schnittstelle. Weiterhin müssen beide als Daemon ständig im Hintergrund laufen. Beide werden über eine zentrale, leicht verständliche Konfigurationsdatei im /etc-Verzeichnis gesteuert. Beide müssen auf annähernd gleiche Weise in Sendmails Konfigurationsdatei verankert werden, was natürlich ihrer Konzeption, wie ein Mail-Filter zu arbeiten, geschuldet ist. Beide kommunizieren über UNIX-Sockets mit Sendmail. Von beiden ist der Quelltext als TGZ-Archiv verfügbar, was lernbegierige Menschen und Sicherheitsfanatiker besonders freut. Auch liegen beide als leicht installierbares RPM-Paket vor. Synonym hier: http://dv8.ro/Synonym/Synonym/source/synonym-0.4-3.i386.rpm und ArchiveSMTP dort: http://oliverseeburger.de/repo/fedora_15/x86_64/extras_seeburger/packages/archivesmtp-1.1.4-3.fc15.x86_64.rpm.
Aber es gibt auch Unterschiede. Erstens: Offensichtlich ist Synonym für 32bit- und ArchiveSMTP für 64bit-Architekturen gebaut worden. Zweitens: Synonym wird zur Zeit nicht mehr aktiv weiterentwickelt und ist inzwischen etwas sehr betagt. Die aktuelle Version datiert vom 26. Oktober 2004. ArchiveSMTP befindet sich aber sehr wohl im Fluß, wenngleich sich die Ereignisse aber auch hier nicht überschlagen. Hier datiert die letzte stabile Version vom 25. November 2010, zur Zeit gibt es einen Release Kandidaten (08. Mai 2011) und die nächste stabile Version wird eigentlich jeden Moment erwartet. Und Drittens gibt es aufgrund des Altersunterschiedes auch einen Unterschied was den Startvorgang angeht, so verwendet Synonym noch ein klassisches SysVinit-Startscript während ArchiveSMTP Fedora 15 konform über systemd gestartet wird (Was aber dem Paketierer, also mir, zu verdanken ist und was bei Synonym auch leicht erreicht werden könnte).
Deshalb werde ich mich im Folgenden nur noch auf ArchiveSMTP konzentrieren. Es sei aber angemerkt, daß Synonym bei mir lange Jahre fehlerlos und ohne zu Murren vor sich hin gewerkelt hat. Ich zolle hiermit den rumänischen Entwicklern von Modulo Consulting meinen tiefempfundenen Respekt.
Die Installation
Bevor man ArchiveSMTP verwenden kann, muß es logischerweise erst einmal überhaupt vorhanden sein. Sprich, es muß zunächst installiert werden. ArchiveSMTP ist bedauerlicherweise nicht Bestandteil der üblicherweise verwendeten Fedora Repositorys. Aber ich habe ein Paket für mein eigenes Repository gebaut. Wer mein eigenes Repository noch nicht verwendet, muß es zunächst in seine Repository-Liste aufnehmen. Keine Angst, Ihre bereits eingerichteten Repositorys werden hierdurch nicht berührt, es kommt lediglich meines noch dazu. Auch bestehen keinerlei Inkompatibilitäten oder Überschneidungen, da ich selber nur Pakete aufnehme, die noch nirgendwo anders zu finden sind. Also, das Aufnehmen meines Repositorys in Ihre Repository-Liste geht so:
[root@vv06 ~]# curl -o /etc/yum.repos.d/fedora_15-x86_64-extras_seeburger.repo -R http://oliverseeburger.de/repo/fedora_15/x86_64/extras_seeburger/repoinit/fedora_15-x86_64-extras_seeburger.repo
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1231 100 1231 0 0 429 0 0:00:02 0:00:02 --:--:-- 828
[root@vv06 ~]#
Und nun folgt das eigentliche Installieren:
[root@vv06 ~]# yum install archivesmtp fc15-x86_64-base_release | 2.0 kB 00:00 fc15-x86_64-base_release/primary_db | 15 MB 00:00 fc15-x86_64-base_updates | 2.0 kB 00:00 fc15-x86_64-base_updates/primary_db | 10 MB 00:00 fc15-x86_64-extras_seeburger | 2.0 kB 00:00 fc15-x86_64-extras_seeburger/primary_db | 11 kB 00:00 Einrichten des Installationsprozess Löse Abhängigkeiten auf --> Führe Transaktionsprüfung aus ---> Package archivesmtp.x86_64 0:1.1.4-3.fc15 will be installiert --> Verarbeite Abhängigkeiten: libmilter.so.1.0()(64bit) für Paket: archivesmtp-1.1.4-3.fc15.x86_64 --> Führe Transaktionsprüfung aus ---> Package sendmail-milter.x86_64 0:8.14.5-1.fc15 will be installiert --> Abhängigkeitsauflösung beendet Abhängigkeiten aufgelöst ================================================================================ Paket Arch Version Repository Grösse ================================================================================ Installieren: archivesmtp x86_64 1.1.4-3.fc15 fc15-x86_64-extras_seeburger 29 k Installiert für Abhängigkeiten: sendmail-milter x86_64 8.14.5-1.fc15 fc15-x86_64-base_updates 64 k Vorgangsübersicht ================================================================================ Install 2 Package(s) Gesamte Downloadgrösse: 94 k Installed size: 113 k Ist dies in Ordnung? [j/N] :j Lade Pakete herunter: (1/2): archivesmtp-1.1.4-3.fc15.x86_64.rpm | 29 kB 00:00 Warnung: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, Schlüssel-ID b78e038c: NOKEY Öffentlicher Schlüssel für archivesmtp-1.1.4-3.fc15.x86_64.rpm ist nicht installiert (2/2): sendmail-milter-8.14.5-1.fc15.x86_64.rpm | 64 kB 00:00 -------------------------------------------------------------------------------- Gesamt 940 kB/s | 94 kB 00:00 Retrieving key from http://oliverseeburger.de/repo/fedora_15/x86_64/extras_seeburger/security/rpm_gpg_key-x86_64-extras_seeburger.txt Importing GPG key 0xB78E038C: Userid: "Oliver Seeburger <oliver.seeburger@sundermeier-werkzeugbau.de>" From : http://oliverseeburger.de/repo/fedora_15/x86_64/extras_seeburger/security/rpm_gpg_key-x86_64-extras_seeburger.txt Ist dies in Ordnung? [j/N] :j Führe rpm_check_debug durch Führe Verarbeitungstest durch Verarbeitungstest erfolgreich Führe Verarbeitung durch Installieren : sendmail-milter-8.14.5-1.fc15.x86_64 1/2 Installieren : archivesmtp-1.1.4-3.fc15.x86_64 2/2 Installiert: archivesmtp.x86_64 0:1.1.4-3.fc15 Abhängigkeit installiert: sendmail-milter.x86_64 0:8.14.5-1.fc15 Komplett! [root@vv06 ~]#
Man erkennt hier, daß bei der Installation von ArchiveSMTP automatisch das Paket sendmail-milter mit installiert wurde. Dieses Paket beinhaltet die Milter-Schnittstelle von Sendmail.
Die Konfiguration
Schauen wir uns zunächst die Konfigurationsdatei von ArchiveSMTP an. Sie hat den Namen archivesmtp.conf und liegt direkt im /etc-Verzeichnis. Und so sieht sie im Auslieferungszustand aus:
{ From Ends "@domain.com" } Store In "/tmp/archivesmtp.mbox";
Ja, richtig, die Konfigurationsdatei besteht nur aus einer einzigen Zeile. Mehr ist manchmal nicht nötig. Im Klartext bedeutet sie, daß immer dann, wenn ArchivsSMTP von Sendmail eine E-Mail übergeben bekommt, ArchiveSMTP zunächst prüft, ob die E-Mail von jemandem stammt, dessen E-Mail Adresse auf @domain.com endet. Also bei helmut.kohl@domain.com oder bei gerhard.schroeder@domain.com wäre das der Fall, nicht aber bei angela.merkel@beispiel.de. Und wenn das der Fall ist, dann legt ArchiveSMTP ein Kopie dieser E-Mail in die Datei /tmp/archivesmtp.mbox ab. Anschließend gibt ArchiveSMTP die E-Mail unverändert wieder an Sendmail zur Weiterverarbeitung zurück. Weitere Informationen zur Konfiguration findet man im Verzeichnis /usr/share/doc/archivesmtp-1.1.4 und hier sei ausdrücklich auf die Dateien archivesmtp.conf.sample und README verwiesen.
Will man nun von allen E-Mails, die von root stammen eine Kopie in der besagten Datei /tmp/archivesmtp.mbox zurückbehalten, so muß man die Konfigurationsdatei /etc/archivesmtp.conf wie folgt ändern:
{ From Starts "root@" } Store In "/tmp/archivesmtp.mbox";
Und um sicherzugehen, daß später auch alles klappt, legen wir noch händisch eine leere Datei archivesmtp.mbox im Verzeichnis /tmp an. Dazu führe ich die folgenden Befehle aus:
[root@vv06 ~]# cd /tmp [root@vv06 tmp]# touch archivesmtp.mbox [root@vv06 tmp]# chmod 644 archivesmtp.mbox [root@vv06 tmp]# chown root archivesmtp.mbox [root@vv06 tmp]# chgrp root archivesmtp.mbox [root@vv06 tmp]# ls -al archivesmtp.mbox -rw-r--r--. 1 root root 0 19. Okt 12:16 archivesmtp.mbox [root@vv06 tmp]# cd [root@vv06 ~]#
Die Inbetriebnahme
Ich habe es weiter oben schon erwähnt, ArchiveSMTP wird nicht mehr - wie das noch in Fedora 14 üblich war - über SysVinit in Betrieb genommen sondern über systemd. Ich zeige jetzt mal wie das geht:
[root@vv06 ~]# systemctl status archivesmtp.service archivesmtp.service - e-mail filtering program that uses the milter API Loaded: loaded (/lib/systemd/system/archivesmtp.service) Active: inactive (dead) CGroup: name=systemd:/system/archivesmtp.service [root@vv06 ~]# systemctl start archivesmtp.service [root@vv06 ~]# systemctl status archivesmtp.service archivesmtp.service - e-mail filtering program that uses the milter API Loaded: loaded (/lib/systemd/system/archivesmtp.service) Active: active (running) since Wed, 19 Oct 2011 12:29:49 +0200; 5s ago Process: 1325 ExecStartPre=/bin/chgrp root /var/run/archivesmtp (code=exited, status=0/SUCCESS) Process: 1323 ExecStartPre=/bin/chown root /var/run/archivesmtp (code=exited, status=0/SUCCESS) Process: 1321 ExecStartPre=/bin/chmod 755 /var/run/archivesmtp (code=exited, status=0/SUCCESS) Process: 1319 ExecStartPre=/bin/mkdir -p /var/run/archivesmtp (code=exited, status=0/SUCCESS) Main PID: 1327 (archivesmtp) CGroup: name=systemd:/system/archivesmtp.service └ 1327 /usr/sbin/archivesmtp -f /etc/archivesmtp.conf -p unix:/var/run/archivesmtp/archivesmtp.sock -r /var/run/archivesmtp/archivesmtp.pid -u root & [root@vv06 ~]#
Der Befehl "systemctl start archivesmtp.service" startet ArchiveSMTP. Analog würde "systemctl stop archivesmtp.service" ArchiveSMTP beenden und mit "systemctl status archivesmtp.service" kann man sich einen Überblick über den aktuellen Zustand dieses Programms verschaffen. Die Zeile "Active: inactive (dead)" bedeutet, daß ArchiveSMTP nicht läuft und entsprechend zeigt "Active: active (running)" an, daß ArchiveSMTP gegenwärtig läuft. Interessant sind auch die Zeilen die mit "Process:" beginnen. Sie informieren darüber, daß systemd bevor es ArchiveSMTP gestartet hat noch das Verzeichnis /var/run/archivesmtp angelegt und mit den adäquaten Rechten versehen hat. In diesem Verzeichnis findet sich dann unmittelbar danach der UNIX-Socket (das ist die Datei /var/run/archivesmtp/archivesmtp.sock), den Sendmail zur Kommunikation mit ArchiveSMTP benutzt.
Wenn Sie in Zukunft Ihren Rechner neu starten, sorgt systemd automatisch dafür daß ArchiveSMTP mitstartet. Dafür hat seinerzeit schon rpm bei der Installation von ArchiveSMTP gesorgt, so daß Sie sich hier um nichts mehr sorgen müssen.
Die Einbindung
Zwar läuft ArchiveSMTP nun schon und funktioniert im Prinzip auch. Passieren tut aber rein gar nichts. Schuld daran ist aber nicht ArchiveSMTP sondern vielmehr Sendmail. Und zwar übergibt im Moment Sendmail noch keine einzige E-Mail an ArchiveSMTP. Und wenn ArchiveSMTP keine E-Mail vorgelegt bekommt, fehlt schlicht und einfach das Futter um irgendetwas zu tun. Wir müssen also nun dafür sorgen, daß Sendmail ArchiveSMTP auch über seine Milter-Schnittstelle in die Arbeit einbezieht. Natürlich bedeutet das wieder einmal mehr die Änderung einer Konfigurationsdatei. In diesem Fall muß die Datei /etc/mail/sendmail.mc bearbeitet werden. Konkret werden zwei Zeilen an das Ende dieser Datei angefügt. Ich zeige nur die relevante Stelle:
. . . MAILER(smtp)dnl MAILER(procmail)dnl dnl MAILER(cyrusv2)dnl MAIL_FILTER(`archivesmtp', `S=unix:/var/run/archivesmtp/archivesmtp.sock') define(`confINPUT_MAIL_FILTERS', `archivesmtp')
Einige Worte zur Erläuterung. Die vorletzte Zeile bewirkt noch gar nichts. Hier wird lediglich ein Mail-Filter Programm definiert. Es wird gesagt es gibt ein Programm und das soll archivesmtp heißen und man kann mit diesem Programm über den UNIX-Socket /var/run/archivesmtp/archivesmtp.sock kommunizieren. Auch der Name archivesmtp ist prinzipiell wurscht. Es macht zwar Sinn dieses Programm archivesmtp zu nennen, wenn es in Wirklichkeit auch ArchiveSMTP heißt, aber man hätte es auch Peter oder Paul nennen können. Einzige Bedingung ist, wenn man dann in der letzten Zeile auch Peter oder Paul schreiben würde. Peter oder Paul oder archivesmtp stellen somit eigentlich nur die Verbindung von der vorletzten zur letzten Zeile her. Wichtig ist zunächst nur der Socket, den muß es im laufenden Betrieb später auch tatsächlich geben. Erst die letzte Zeile schafft dann Fakten. Sie weist Sendmail an dieses Gebilde namens archivesmtp auch zu verwenden.
Es gibt auch die Möglichkeit statt zwei Zeilen nur eine zu benutzen. So kann man alternativ auch einfach schreiben: "INPUT_MAIL_FILTER(`archivesmtp', `S=unix:/var/run/archivesmtp/archivesmtp.sock')". Ich rate dringend davon ab. Wenn man nämlich mehrere Filterprogramme verwendet, dann kann man zunächst alle Filterprogramme in einzelnen MAIL_FILTER-Zeilen definieren und anschließend in der define-Zeile sehr genau die Reihenfolge der Abarbeitung festlegen. Bei der Einzeilenlösung gleicht die Reihenfolge doch eher einem Glücksspiel.
Wenn man jetzt Sendmail neu startet, sollte doch eigentlich alles wie gewünscht funktionieren. Sollte man meinen. Tut es aber nicht. Doch probieren wir es einfach mal aus und schauen was passiert. Dabei interessieren mich besonders zwei Dateien, und zwar /etc/mail/sendmail.cf und /etc/mail/sendmail.mc, die ich deshalb im Folgenden genauer betrachten möchte.
[root@vv06 ~]# ls -al /etc/mail/sendmail* -rw-r--r--. 1 root root 58502 17. Mai 18:32 /etc/mail/sendmail.cf -rw-r--r--. 1 root root 7429 19. Okt 14:10 /etc/mail/sendmail.mc [root@vv06 ~]# systemctl restart sendmail.service [root@vv06 ~]# ls -al /etc/mail/sendmail* -rw-r--r--. 1 root root 58502 17. Mai 18:32 /etc/mail/sendmail.cf -rw-r--r--. 1 root root 7429 19. Okt 14:10 /etc/mail/sendmail.mc [root@vv06 ~]#
Die Datei /etc/mail/sendmail.mc war ja die von mir soeben veränderte Konfigurationsdatei. Sie hat sich durch den Sendmail-Neustart nicht geändert (soweit man das bei einem einfachen ls-Befehl überhaupt beurteilen kann). Sie darf sich aber auch nicht ändern. Das wäre ja noch schöner, wenn ein Programm seine eigene Konfiguration ändern würde. Interessanter ist aber, daß sich die Datei /etc/mail/sendmail.cf augenscheinlich auch nicht geändert hat. Die hätte sich aber ändern müssen.
Wir haben es hier mit einer Besonderheit von Sendmail zu tun. Sendmail besitzt eine tendenziell eher menschenlesbare einfache Konfigurationsdatei, die .mc Datei, und eine davon abgeleitete tendenziell eher maschinenlesbare komplizierte Konfigurationsdatei, die .cf Datei. Bei einem Neustart von Sendmail generiert Sendmail dann aus der .mc Datei die .cf Datei. Genau dies hat hier offensichtlich nicht geklappt. Da wir eben die .mc Datei bearbeitet hatten, hätte sich nach dem Sendmail Neustart die .cf Datei verändern müssen. Hat Sie aber nicht. Ich will Sie nicht länger auf die Folter spannen. Des Rätsels Lösung ist ein fehlendes rpm-Paket, und zwar sendmail-cf. Dieses Paket ist nicht Bestandteil der Fedora Minimalinstallation und muß deshalb nachinstalliert werden.
[root@vv06 ~]# yum install sendmail-cf Einrichten des Installationsprozess Löse Abhängigkeiten auf --> Führe Transaktionsprüfung aus ---> Package sendmail-cf.noarch 0:8.14.5-1.fc15 will be installiert --> Abhängigkeitsauflösung beendet Abhängigkeiten aufgelöst ================================================================================ Paket Arch Version Repository Grösse ================================================================================ Installieren: sendmail-cf noarch 8.14.5-1.fc15 fc15-x86_64-base_updates 182 k Vorgangsübersicht ================================================================================ Install 1 Package(s) Gesamte Downloadgrösse: 182 k Installed size: 938 k Ist dies in Ordnung? [j/N] :j Lade Pakete herunter: sendmail-cf-8.14.5-1.fc15.noarch.rpm | 182 kB 00:00 Führe rpm_check_debug durch Führe Verarbeitungstest durch Verarbeitungstest erfolgreich Führe Verarbeitung durch Installieren : sendmail-cf-8.14.5-1.fc15.noarch 1/1 Installiert: sendmail-cf.noarch 0:8.14.5-1.fc15 Komplett! [root@vv06 ~]#
Nachdem das erledigt ist, versuchen wir erneut einen Sendmail Neustart. Auch nun will ich wieder beobachten was mit den beiden Dateien sendmail.cf und sendmail.mc geschieht.
[root@vv06 ~]# ls -al /etc/mail/sendmail* -rw-r--r--. 1 root root 58502 17. Mai 18:32 /etc/mail/sendmail.cf -rw-r--r--. 1 root root 7429 19. Okt 14:10 /etc/mail/sendmail.mc [root@vv06 ~]# systemctl restart sendmail.service Job failed. See system logs and 'systemctl status' for details. [root@vv06 ~]# ls -al /etc/mail/sendmail* -rw-r--r--. 1 root root 59207 19. Okt 14:15 /etc/mail/sendmail.cf -rw-r--r--. 1 root root 58502 17. Mai 18:32 /etc/mail/sendmail.cf.bak -rw-r--r--. 1 root root 7429 19. Okt 14:10 /etc/mail/sendmail.mc [root@vv06 ~]#
Jetzt habe ich zwar vordergründig das erhoffte Ergebnis erzielt. Man sieht eine signifikante Veränderung bei Größe und Datum der sendmail.cf Datei, während die sendmail.mc Datei unverändert bleibt. Auch ist automatisch eine Sicherungsdatei sendmail.cf.bak angelegt worden. Wer die Veränderung ganz genau beobachten will, der kann nun auch noch den Befehl "diff /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak" absetzen.
Aber halt, was war das? Ich bin alles andere als zufrieden. Der systemctl Befehl hat mit "Job failed." geantwortet. Das hätte nicht passieren dürfen. Es geht also immer noch nicht. Nun, woran liegt's? Schauen wir uns einmal Sendmails Log-Datei an. Am Ende der Datei /var/log/maillog finden wir da die folgende Zeile:
Oct 24 11:43:20 vv06 sendmail[960]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1692: Xarchivesmtp: local socket name /var/run/archivesmtp/archivesmtp.sock unsafe: Permission denied
Das ist komisch. Man denkt zunächst, daß die Zugriffsrechte am UNIX-Socket von ArchiveSMTP falsch gesetzt sind. Aber auch nach mehrmaliger Kontrolle ist kein Fehler feststellbar. Jedoch könnte der Ausdruck "Permission denied" auch auf ein SE-Linux Problem hindeuten. Deshalb folgt nun noch ein Blick in die Datei /var/log/audit/audit.log. Und tatsächlich, hier finden sich Fehlermeldungen im Zusammenhang mit Sendmail und ArchiveSMTP. Dies sind die einschlägigen Zeilen (natürlich auch ganz am Ende der Datei zu finden):
type=AVC msg=audit(1319449400.133:43): avc: denied { getattr } for pid=960 comm="sendmail" path="/run/archivesmtp/archivesmtp.sock" dev=tmpfs ino=11063 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file type=SYSCALL msg=audit(1319449400.133:43): arch=c000003e syscall=6 success=no exit=-13 a0=7fff1d5dfe30 a1=7fff1d5dfda0 a2=7fff1d5dfda0 a3=7fff1d5dfe55 items=0 ppid=959 pid=960 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) type=SERVICE_START msg=audit(1319449400.287:44): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="sendmail" exe="/bin/systemd" hostname=? addr=? terminal=? res=failed'
Bang! Offensichtlich hat jetzt SE-Linux mit seiner ganzen Macht zugeschlagen. Vorerst weiß ich mir nicht anders zu helfen, als SE-Linux versuchsweise ganz abzuschalten. Ich editiere deshalb die Datei /etc/selinux/config wie folgt:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
Jetzt folgt der obligatorische Rechnerneustart. Und danach schauen wir, ob Sendmail ohne Probleme einen Restart verträgt.
[root@vv06 ~]# systemctl restart sendmail.service
[root@vv06 ~]#
In der Tat: Die Ursache war SE-Linux. Das gefällt mir jetzt aber gar nicht. Ich weiß zwar um die Schwierigkeiten, die es bereitet, die Vielzahl der mehr oder weniger bekannten E-Mail-Filter alle korrekt im Sendmailkontext ausführen zu lassen, aber SE-Linux einfach ganz abzustellen kann nicht die Lösung sein, schließlich ist ja gerade SE-Linux eines der Alleinstellungsmerkmale von Fedora. Aber bevor ich das SE-Linux Problem angehe, will ich zunächst wissen ob ArchiveSMTP nun endlich seinen Dienst tut. Fehlerlose Log-Dateien sind schließlich auch noch keine Garantie dafür, daß ArchiveSMTP nun wie gewünscht läuft. Gewißheit bringt erst der nun folgende Test.
Der Versuch
Nun folgt der ultimative Test. Und zwar möchte ich so einfach, wie nur irgend möglich testen. Insbesondere möchte ich nicht erst ein Evolution oder einen Thunderbird installieren. Ich installiere stattdessen mailx. Das ist der minimalistischste Mailer den ich kenne. Es wird nur ein einziges Paket installiert, da keine weiteren Abhängigkeiten bestehen. Dieses Paket bringt nur 13 Dateien mit insgesamt 451kB auf die Festplatte und läßt sich auch absolut rückstandsfrei deinstallieren. Also wie gehabt:
[root@vv06 ~]# yum install mailx Einrichten des Installationsprozess Löse Abhängigkeiten auf --> Führe Transaktionsprüfung aus ---> Package mailx.x86_64 0:12.5-3.fc15 will be installiert --> Abhängigkeitsauflösung beendet Abhängigkeiten aufgelöst ================================================================================ Paket Arch Version Repository Grösse ================================================================================ Installieren: mailx x86_64 12.5-3.fc15 fc15-x86_64-base_release 234 k Vorgangsübersicht ================================================================================ Install 1 Package(s) Gesamte Downloadgrösse: 234 k Installed size: 451 k Ist dies in Ordnung? [j/N] :j Lade Pakete herunter: mailx-12.5-3.fc15.x86_64.rpm | 234 kB 00:00 Führe rpm_check_debug durch Führe Verarbeitungstest durch Verarbeitungstest erfolgreich Führe Verarbeitung durch Installieren : mailx-12.5-3.fc15.x86_64 1/1 Installiert: mailx.x86_64 0:12.5-3.fc15 Komplett! [root@vv06 ~]#
Ich zeige nun zuerst, daß die Archivdatei /tmp/archivesmtp.mbox zu Anfang noch leer ist. Zweitens versende ich als root eine kleine Testmail ebenfalls an root. Und drittens zeige ich, daß danach die Archivdatei eben diese Testmail enthält.
[root@vv06 ~]# ls -al /tmp/archivesmtp.mbox -rw-r--r--. 1 root root 0 24. Okt 13:12 /tmp/archivesmtp.mbox [root@vv06 ~]# mail root@localhost Subject: Test Test . EOT [root@vv06 ~]# ls -al /tmp/archivesmtp.mbox -rw-r--r--. 1 root root 590 24. Okt 13:12 /tmp/archivesmtp.mbox [root@vv06 ~]#
Es hat also geklappt. Die wahre Mail an root finden Sie nun in der Datei /var/spool/mail/root und die zurückbehaltene Kopie finden Sie hier: /tmp/archivesmtp.mbox. Schauen Sie sich doch beides einmal an. Dazu können Sie "cat /var/spool/mail/root" bzw. "cat /tmp/archivesmtp.mbox" oder auch "mail -f /var/spool/mail/root" und entsprechend "mail -f /tmp/archivesmtp.mbox" verwenden. Wenn Sie den "mail -f" Befehl verwenden, können Sie sich die einzelnen E-Mails mit "t1", "t2", "t3" usw. anzeigen lassen. Ein "exit" beendet den "mail -f" Befehl wieder.
Im Prinzip sind wir damit durch. Es bleibt allerdings noch mein SE-Linux Problem. Meine Tests führe ich immer auf einer Fedora Minimalinstallation in einer virtuellen Maschine aus. Das hat Vorteile, denn man erkennt unaufgelöste Abhängigkeiten sehr schnell. Das hat aber auch Nachteile, weil viele nützliche Tools fehlen, die manchmal wertvolle Hilfestellung liefern. Wenn man nämlich alle die oben erwähnten Schritte auf einem voll ausgestatteten Fedora ausgeführt hätte, dann hätte Fedora für mein SE Problem selbständig eine Lösung vorgeschlagen. So soll man nacheinander die folgenden Befehle absetzen: Zunächst "grep sendmail /var/log/audit/audit.log | audit2allow -M mypol" und danach "semodule -i mypol.pp". Das auszuprobieren überlasse ich Ihnen, es soll ja für Sie spannend bleiben.