Nach der gestrigen Installation von maildrop 2.0.2 hoffte ich noch, dass es keine Probleme gibt. Aber es kommt immer anders als man denkt. In der SysCP Maildrop INSTALL Dokumentation fehlt nämlich ein sehr wichtiger Hinweis. Via Google habe ich ihn in einem Mailinglisten-Archiv gefunden: Wenn man maildrop mit der courier-authlib benutzt, muss maildrop in der Postfix master.cf mit root-Rechten ausgeführt werden:
maildrop unix - n n - - pipe
flags=DRhu user=root argv=/usr/bin/maildrop -d ${recipient}
Mit user=vmail klappts bei Debian etch nicht mehr. Jetzt kann das Setup weiter gehen. Als nächstes gehts ans Spamassassin trainieren und konfigurieren. Der meldet sich nämlich noch nicht.
Update 01.05.07 Leider weigert sich das Postfix pipe Kommando Befehle mit root-Rechten auszuführen. Diese Weigerung führt dazu, das die Zustellung über den maildrop Transport nicht funktioniert. Ich teste gerade eine andere Möglichkeit wie man maildrop ohne Patch verwenden kann.
Pingback: Volkers Blog » Blog Archiv » Debian Etch + SysCP + SpamAssassin
Hallo Volker,
vielen Dank für die wertvollen Hinweise in deinem Blog! Sie haben mich auf der Suche nach einer Lösung des maildrop-selbst-kompilieren-Problems sehr weit gebracht.
Das Problem mit dem User root in der Postfix pipe lässt sich relativ leicht umgehen, wenn man maildrop setuid setzt. Dann kann man den Benutzer vmail weiterhin benutzen (was Postfix sehr nett findet) und hat trotzdem die nötigen Chefrechte.
Grüße,
Dominik
Hallo,
ich weiß auch nicht mehr genau was da bei mir schief ging. Ich habe auch irgendwann während der Installation das setuid gesetzt und dann gings…
Volker
Ich habe geraden einen neuen Server mit syscp+courier+spamassassin+clamav aufgesetzt. Die größten Schwierigkeiten macht eigentlich nur die Tatsache, die Du schon beschrieben hast: dass maildrop keinen Zugriff auf den Socket von courier-authlib zugreifen kann. Nachdem ich maildrop setuid root ausführe klappt aber alles (ich nutze den Server nur für mich, da spielt die mangelnde Sicherheit nicht die Riesenrolle).
Hi,
das Problem liess sich bei mir mit:
chown vmail:daemon /var/run/courier/authdaemon/
lösen.
MfG
Olaf
jo mit:
chown vmail /var/run/courier/authdaemon
lässt sich’s wieder mails empfangen.