Thomas Ziegler <zie(_at_)iis(_dot_)fhg(_dot_)de> writes:
...
Later I realized that mails, sent by colleagues did not arrive me (I saw
their outgoing copies). After I was the only guy, who lost mail, it seems
that it's the procmail based filter (BTW: procmail v3.11pre7 1997/04/28).
Because of these errors, I'm a little bit afraid to setup the same filter,
only with logging enabled. I need to know, if it's possible that
- procmail accidentally can overwrite incoming mail, if it is started by
cron, reads from the system folder and writes unfiltered mails back to
system folder again?
It depends. Which form or forms of mailbox locking are used by the
local delivery agent on the mailserver? Was procmail compiled to use
those same forms?
- there is an interaction of procmail with my mailer (mutt), which is also
working on the system folder?
What locking does mutt use?
If you invoke procmail from a cronjob, filtering from your system mailbox
back into your system mailbox, then each message not delivered elsewhere
may be processed by procmail many times. In general, means extra work for
procmail, but in particular is completely breaks the standard duplicate
suppression recipes, because formail will see as a duplicate any message
left in your system mailbox for more than one invocation of procmail!
I would suggest that you use some other file as your 'post-procmail'
spool, directing mutt to read from it instead of your 'real' spool.
The mail would then flow like this:
received by MTA
|
V
system spool file
|
V
cronjob invokes procmail --> personal mail folders
DEFAULT=$HOME/.spool
|
V
$HOME/.spool
|
V
mutt
Philip Guenther