Verstaendnisfrage: postfix+procmail+courier-imap

[Knappe]

Mailserver mit
- fetchmail
- postfix
- SpamAssassin
- courier-imap
laeuft bei mir seit Monaten problemlos.

Moechte jetzt procmail zum Einsortieren der Mails in verschiedene Mailordner und Unterordner verwenden.

Dabei soll postfix als MDA weiterhin erhalten bleiben, da nicht nur Mails via fetchmail von externen Postfaechern abgeholt, sondern auch interne Mails durch procmail bearbeitet werden sollen.

Genau das klappt aber nicht, daher nachstehend mal meine Konfigurationen (bzw. Auszuege davon) :

/etc/postfix/main.cf

...
#mailbox_command = /some/where/procmail -a "$EXTENSION" ----------------->NICHT GESETZT (SIEHE KOMMENTRARE in MAIN.CF ZU mailbox_transport !!!!!!!!)
mailbox_transport = procmail
...

Jetzt die /etc/postfix/master.cf :

procmail unix - n n - - pipe
flags=R user=mail argv=/usr/bin/procmail -t -m USER=${user} EXT=${extension} /etc/procmailrc

Trotz googeln habe ich nicht herausgefunden, wie die Definition in der master.cf gemacht werden muss, damit procmail NUR die procmailrc aus den Homeverzeichnissen der User verwendet (ohne Angabe von /etc/procmailrc erhalte ich Fehlermeldungen in /var/log/messages).

So hier jetzt mal die /etc/procmailrc :

DELIVERMAIL="$HOME/Maildir"
LOGFILE="$HOME/procmail.log"
IMAP="$DELIVERMAIL/INBOX"
BACKUP="$DELIVERMAIL/.backup"
SPAMIT="$DELIVERMAIL/.Junk or suspicious mail"
VERBOSE=yes # genaue (Fehler-)Meldungen?

#create a backup of each mail
:0 c
| $BACKUP

#Spam filter einfachster Art
:0
* ^Subject: ***SPAM***
| $SPAMIT

#Deliver to user inbox
:0 w
| $IMAP

:0 w
{
EXITCODE=$?
host
}

Obwohl das Logfile angelegt ist, wird ueberhaupt nichts dort hineingeschrieben.

Jetzt habe ich mal eine interne Mail versendet. Anliegend der Auszug aus /var/log/mail :

Nov 1 15:05:02 myserver postfix/smtpd[7071]: connect from localhost[127.0.0.1]
Nov 1 15:05:02 myserver postfix/smtpd[7071]: DF12A343803A9: client=localhost[127.0.0.1]
Nov 1 15:05:02 myserver postfix/cleanup[7063]: DF12A343803A9: message-id=<4548B7B6.23987.3F350D64@info.mydomain.de>
Nov 1 15:05:02 myserver postfix/qmgr[7042]: DF12A343803A9: from=<info@mydomain.de>, size=1998, nrcpt=1 (queue active)
Nov 1 15:05:02 myserver postfix/smtpd[7071]: disconnect from localhost[127.0.0.1]
Nov 1 15:05:02 myserver amavis[31127]: (31127-07) Passed CLEAN, [192.168.2.100] <info@mydomain.de> -> <otto@myserver.mydomain.de>, Message-ID: <4548B7B6.23987.3F350D64@info.mydomain.de>, mail_id: VeJAToRre6gQ, Hits: -3.11, 2445 ms
Nov 1 15:05:03 myserver postfix/lmtp[7064]: 72C4D34024B65: to=<otto@myserver.mydomain.de>, orig_to=<otto@mydomain.de>, relay=127.0.0.1[127.0.0.1], delay=3, status=sent (250 2.6.0 Ok, id=31127-07, from MTA([127.0.0.1]:10025): 250 Ok: queued as DF12A343803A9)
Nov 1 15:05:03 myserver postfix/qmgr[7042]: 72C4D34024B65: removed
Nov 1 15:05:03 myserver postfix/pipe[7073]: DF12A343803A9: to=<otto@myserver.mydomain.de>, relay=procmail, delay=1, status=sent (myserver.mydomain.de)
Nov 1 15:05:03 myserver postfix/qmgr[7042]: DF12A343803A9: removed
Nov 1 15:05:31 myserver imapd: Connection, ip=[::ffff:192.168.2.100]

Daraus meine ich ersehen zu koennen, dass postfix tatsaechlich procmail aufruft (relay=procmail), keine Rueckmeldung von procmail erhaelt und abschliessend die Message/Mail aus seine Queue (richtigerweise) loescht.

So, wo ist aber nun die Mail ? Habe wie gesagt keine Logeintraege oder aehnliches gefunden.

Hoffe man kann mir schnell helfen, da im Moment so auch alle ueber fetchmail abgeholten Mails im Nirwana verschwinden !

 

[stka]

Push

 

[nbkr]

Mach mal das Loging von Procmail an - da sollte drin stehen wo Procmail die Mails hinschiebt.

Ach und hier fehlt vermutlich ein / am Ende: "$HOME/Maildir". Dadurch versucht procmail die Mails in die DATEI $HOME/Maildir zu schieben. So: "$HOME/Maildir/" sollte procmail erkennen das es sich um ein Maildirverzeichnis handelt.

 

[Knappe]

Habe inzwischen in der Procmail-Mailinglist die gleiche Fragestellung gestellt und (im Gegensatz zu hier) auch Antworten erhalten.

Der Einfachheit halber der Thread als Kopie hier :

Hi,


Am 3 Nov 2006 um 9:46 hat xxxx geschrieben:

> > On 03 Nov 2006, at 04:36 , mail@xxxxxx wrote:
>> > > mailbox_transport = procmail
> >
> > What I use:
> > mailbox_command = /usr/local/bin/procmail -t -a "$EXTENSION"
same as I do (now), but the goal is to use "mailbox_transport".

> >
>> > > Then the master.cf :
>> > > procmail unix - n n - - pipe
>> > > flags=R user=mail argv=/usr/bin/procmail -t -m USER=${user}
>> > > EXT=${extension} /etc/procmailrc
> >
So every mail in your scenario has the owner "delivery", not the owner of the mailbox-owner himself !
That´s wrong.

> > procmail unix - n n - - pipe
> > -o flags=R user=delivery argv=/usr/local/bin/procmail -t -m USER=$
> > {delivery} EXTENSION=${extension} /usr/local/etc/procmailrc.common
> >
> > NB: It's pipe -o, not pipe
you are right ! Thx.

> >
>> > > BUT : all mails are owned by the "user=..." i.e. "mail" from the entry
>> > > of the master.cf (postfix).
> >
> > Well, as I understood it the user=delivery means that the delivery
> > agent in postfix 'owns' the message, and the delivery agent 'does the
> > right thing'.
Hmm ... what do you mean? The option user=delivery (your example) or user=mail (my example) means,
that this is the user who own´s the following piping (and the delivered mails).
The name "delivery" is a user-name, not any special name from postfix (I never heart about this name in
the postifx-guidelines or docs).

> >
> > I'm not sure why yours is set to 'mail'
It is an entry "user" in the "/etc/passwd". You could add your own user in this file and use it in the
user=...-statement from postfix (and I use "mail")..

> >
>> > > "..after processing aliases and .forward files" are the keywords !
> >
> > Why? Where does the .forward of alias come into play?
>From Postfix ! If defined, Postfix use alias-tables to change recipient-names (and more). I used this table to define
external users with their mailbox-names as internal(local)-users. So everyone could use the external adress. If he is connecte to the
internal LAN, then postfix deliver this email directly & automaticaly to the alias-user-id in the internal net (its easy to handle with adress-
books) not using external SMTP´s or whatever.

____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail@lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

Demzufolge funktioniert der Eintrag in der /etc/postfix/main.cf :

mailbox_command = /usr/local/bin/procmail -t -a "$EXTENSION"

Dagegen funktioniert der Eintrag

mailbox_command=
mailbox_transport = procmail

und entsprechenden Eintrag in der master.cf nicht :evil:


Aber wie auch in den Kommentaren genau in dieser Postfix-Datei steht :

# The mailbox_transport specifies the optional transport in master.cf
# to use after processing aliases and .forward files. This parameter
# has precedence over the mailbox_command, fallback_transport and
# luser_relay parameters.

müsste es funktionieren und dann müßte sich ja auch Postfix anders verhalten ! :roll:

Keiner eine Idee oder einen Hinweis :?:

 

[nbkr]

Also ich hab procmail immer mit

mailbox_command = procmail -m /etc/procmailrc

in die main.cf aufgenommen. (bei dem -m bin ich mir nicht ganz sicher) In der master.cf stand procmail nie drin. In der /etc/procmailrc stand dann ein

include $HOME/.procmailrc

 

[Knappe]

@ nbkr

ja, das machen alle

mailbox_command = procmail -m /etc/procmailrc

ist ja auch auch richtig, außer wenn man

to use after processing aliases and .forward files.

Procmail erst benutzen möchte NACHDEM Postfix noch die Alias-Tabellen (und Forward-Files) gecheckt bzw. ausgeführt hat !

Nach der Postfix-eigenen Beschreibung, wird z.B. diese Alias-Tabelle bei Verwendung des "mailbox_command´s" NICHT mehr interpretiert (sodern eben nur bei "mailbox_transport").

Aber letzteres Kommando funktioniert eben nicht (z.B. wird keine Variable $USER übergeben, auch die $HOME-Variable ist leer (was übrigens auch der Grund für das Schreiben der Prokotollinfo ins Nirwana war)).

Es ist mir bisher auch nicht gelungen herauszufinden, wer für diesen misslichen Zustand die Verantwortung trägt : Postfix oder Procmail :roll:

 

[Knappe]

@ nbkr

hier übrigens noch eine Info aus einem Procmail-Thread zur Verrwendung der Option "-m /etc/procmailrc" :

This is not normal procmail operation. /etc/procmailrc should be read
automatically as the default, and when it is finished (unless it
finished by making a delivery) procmail should fall through to
$HOME/.procmailrc. Neither of these happens in the default way when
you use the -m option.

-->Also, keine "-m ..."-Option nutzen