Hallo Liste,
ich habe ein Problem mit procmail. Ziel ist es, dass spam-emails gleich in das Maildir-Verzeichnis .spam des jeweiligen Users abgelegt werden. Dazu habe ich folgende /etc/procmailrc angelegt:
===== /etc/procmailrc ====== DEFAULT = $HOME/Maildir/ LOGFILE=$HOME/procmail.log LOGABSTRACT=yes VERBOSE=no
## spam-check :0fW | spamassassin -a
:0: * ^X-Spam-Status: Yes $HOME/Maildir/.spam/ ===========================
Als Mailserver kommt postfix zum einsatz. Dort steht in der main.cf:
mailbox_command = procmail -a "$EXTENSION"
Die spam-emails landen mit diesen Einstellungen wunderbar in dem spam-Verzeichnis des jeweiligen Users. Nur habe alle diese mails als Eigentümer root und daher für den User nicht lesbar. Z.B.:
ls -la .spam/new/ -rw------- 1 root mail 5584 Apr 7 16:20 1081347623.10444_1.netgate -rw------- 1 root mail 31031 Apr 7 19:04 1081357491.11490_0.netgate
Wie erreiche ich nun, dass diese mails als Eigentümer den jeweiligen User bekommen?
Grüße aus Kamenz
On Thu, Apr 08, 2004 at 08:49:37AM +0200, Bernd Ledig wrote:
Hallo Liste,
ich habe ein Problem mit procmail. Ziel ist es, dass spam-emails gleich in das Maildir-Verzeichnis .spam des jeweiligen Users abgelegt werden. Dazu habe ich folgende /etc/procmailrc angelegt:
===== /etc/procmailrc ====== DEFAULT = $HOME/Maildir/ LOGFILE=$HOME/procmail.log LOGABSTRACT=yes VERBOSE=no
## spam-check :0fW | spamassassin -a
:0:
- ^X-Spam-Status: Yes
$HOME/Maildir/.spam/
das sieht gut aus.
Als Mailserver kommt postfix zum einsatz. Dort steht in der main.cf:
mailbox_command = procmail -a "$EXTENSION"
spam-Verzeichnis des jeweiligen Users. Nur habe alle diese mails als Eigentümer root und daher für den User nicht lesbar. Z.B.:
das ist seltsam, denn (aus meiner kommentierten main.cf):
# The mailbox_command parameter specifies the optional external # command to use instead of mailbox delivery. The command is run as # the recipient with proper HOME, SHELL and LOGNAME environment settings. # Exception: delivery for root is done as $default_user. # # Other environment variables of interest: USER (recipient username), # EXTENSION (address extension), DOMAIN (domain part of address), # and LOCAL (the address localpart). # # Unlike other Postfix configuration parameters, the mailbox_command # parameter is not subjected to $parameter substitutions. This is to # make it easier to specify shell syntax (see example below). # # Avoid shell meta characters because they will force Postfix to run # an expensive shell process. Procmail alone is expensive enough. # # IF YOU USE THIS TO DELIVER MAIL SYSTEM-WIDE, YOU MUST SET UP AN # ALIAS THAT FORWARDS MAIL FOR ROOT TO A REAL USER. # #mailbox_command = /some/where/procmail #mailbox_command = /some/where/procmail -a "$EXTENSION"
was mich wundert ist, daß dein postfix als root läuft (bzw. den maildrop als root ausführt), denn laut der obigen beschreibung wechselt er jeweils zum auzuliefernden user, bevor er procmail aufruft. Da das mit "$HOME" in der procmailrc auch zu funktionieren scheint, ist es noch verwunderlicher, daß procmail als root läuft. Dein procmail ist nicht zufällig suid root (warum auch immer)?
Wie erreiche ich nun, dass diese mails als Eigentümer den jeweiligen User bekommen?
Sorry, eine genaue Diagnose kann ich auch nicht stellen, aber evtl. sind es ja Tips, wo du suchen mußt.
Ansonsten erzähl mal: welche Versionen, welche Distribution, du weißt schon, was man halt so zur Diagnose braucht.
Hi,
* Bernd Ledig [04-04-08 08:49:37 +0200] wrote:
ich habe ein Problem mit procmail. Ziel ist es, dass spam-emails gleich in das Maildir-Verzeichnis .spam des jeweiligen Users abgelegt werden. Dazu habe ich folgende /etc/procmailrc angelegt:
[...]
Wie erreiche ich nun, dass diese mails als Eigentümer den jeweiligen User bekommen?
Meine procmail-Manpage sagt, dass procmail alles aus der systemweiten Konfigurationsdatei stets als User root ausführt -- und zwar bevor die procmailrc des Users abgearbeitet wird. Also müsste es helfen, wenn du nur den Test systemweit, das Verschieben aber auf User-Ebene machst.
bye, Rocco
Hallo,
Rocco Rutte wrote:
[...]
Meine procmail-Manpage sagt, dass procmail alles aus der systemweiten Konfigurationsdatei stets als User root ausführt -- und zwar bevor die procmailrc des Users abgearbeitet wird. Also müsste es helfen, wenn du nur den Test systemweit, das Verschieben aber auf User-Ebene machst.
Genau, das wars. Nach dem Anlegen einer .procmailrc im jeweiligen Home des Users mit der Verschiebeanweisung stimmen die Dateirechte/eigentümer.
Danke für den Typ.
Jetzt brauch ich aber einen Typ, wie man für ca. 100 User dieses Anlegen der .procmailrc nachträglich mit wenig Aufwand hinbekommet. Ich möchte ungern händisch diese Dateien in das jeweilige Home kopieren und die Rechte setzen.
Grüße aus Kamenz
Bernd Ledig
On 09.04.04 Bernd Ledig (bernd@ledig.info) wrote:
Moin,
Jetzt brauch ich aber einen Typ, wie man für ca. 100 User dieses Anlegen der .procmailrc nachträglich mit wenig Aufwand hinbekommet. Ich möchte ungern händisch diese Dateien in das jeweilige Home kopieren und die Rechte setzen.
z.B.:
#!/bin/bash unalias ls; cd home for i in `ls`; do [ -f $i/.procmailrc ] || cp /template/procmailrc $i/.procmailrc; \ chown $i:users $i/.procmailrc done
problems: - geht davon aus, daß alle User in /home liegen und zur Gruppe users gehören - geht davon aus, daß in /home nur Verzeichnisse liegen - lget in lost+found auch eine an - keine Sonderzeichen im Usernamen (dürfte eh nicht gehen)
H.
Na dann suche mal in der Hilfe! Pass auf das der nächste Beitrag nicht RTFM enthält! *g*
Hilmar Preusse wrote:
On 09.04.04 Bernd Ledig (bernd@ledig.info) wrote:
Moin,
Jetzt brauch ich aber einen Typ, wie man für ca. 100 User dieses Anlegen der .procmailrc nachträglich mit wenig Aufwand hinbekommet. Ich möchte ungern händisch diese Dateien in das jeweilige Home kopieren und die Rechte setzen.
z.B.:
#!/bin/bash unalias ls; cd home for i in `ls`; do [ -f $i/.procmailrc ] || cp /template/procmailrc $i/.procmailrc; \ chown $i:users $i/.procmailrc done
problems:
- geht davon aus, daß alle User in /home liegen und zur Gruppe users
gehören
- geht davon aus, daß in /home nur Verzeichnisse liegen
- lget in lost+found auch eine an
- keine Sonderzeichen im Usernamen (dürfte eh nicht gehen)
H.
Häh... *peinlich* Auf den falschen Beitrag geantwortet! Sorry.
Michael Burkhardt wrote:
Na dann suche mal in der Hilfe! Pass auf das der nächste Beitrag nicht RTFM enthält! *g*
Hilmar Preusse wrote:
On 09.04.04 Bernd Ledig (bernd@ledig.info) wrote:
Moin,
Jetzt brauch ich aber einen Typ, wie man für ca. 100 User dieses Anlegen der .procmailrc nachträglich mit wenig Aufwand hinbekommet. Ich möchte ungern händisch diese Dateien in das jeweilige Home kopieren und die Rechte setzen.
z.B.:
#!/bin/bash unalias ls; cd home for i in `ls`; do [ -f $i/.procmailrc ] || cp /template/procmailrc $i/.procmailrc; \ chown $i:users $i/.procmailrc done
problems:
- geht davon aus, daß alle User in /home liegen und zur Gruppe users
gehören
- geht davon aus, daß in /home nur Verzeichnisse liegen
- lget in lost+found auch eine an
- keine Sonderzeichen im Usernamen (dürfte eh nicht gehen)
H.
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
On 10.04.04 Michael Burkhardt (bahnamt@onlinehome.de) wrote:
Moin,
Na dann suche mal in der Hilfe! Pass auf das der nächste Beitrag nicht RTFM enthält! *g*
Hilmar Preusse wrote:
Auch Dein MUA kann sicher TOFU-freie Mails schreiben. Such mal in der Hilfe...
H.
Hallo,
Hilmar Preusse wrote:
On 09.04.04 Bernd Ledig (bernd@ledig.info) wrote:
Jetzt brauch ich aber einen Typ, wie man für ca. 100 User dieses Anlegen der .procmailrc nachträglich mit wenig Aufwand hinbekommet. Ich möchte ungern händisch diese Dateien in das jeweilige Home kopieren und die Rechte setzen.
z.B.:
#!/bin/bash unalias ls; cd home for i in `ls`; do [ -f $i/.procmailrc ] || cp /template/procmailrc $i/.procmailrc; \ chown $i:users $i/.procmailrc done
problems:
- geht davon aus, daß alle User in /home liegen und zur Gruppe users gehören
- geht davon aus, daß in /home nur Verzeichnisse liegen
- lget in lost+found auch eine an
- keine Sonderzeichen im Usernamen (dürfte eh nicht gehen)
Obige Probleme treffen hier nicht zu. Script arbeitet deshalb hervorragend.
Danke
Gruß Bernd Ledig
lug-dd@mailman.schlittermann.de