I will try and be brief while ellaborating the problem clearly. This
is probably not a problem with procmail, but advice that I need which
I did not find when looking through FAQs or the excellent pm-tips URL.
Our Setup
=========
Sendmail receives incoming mail. It fires up procmail to read users'
~/.procmailrc (and any INCLUDERC'ed) files. The system-wide mail spool
is a Cyrus-based IMAP spool. This means that all mail not delivered in
a user's ~/.procmailrc should be piped through a special delivery
agent, NOT writen to a file. Piping to the delivery agent is done in a
global /etc/procmailrc file. It's a relatively short file, of the
form:
<SET_SOME_VARIABLES>
DROPPRIVS
<SOURCE_USER_CONFIG>
<PIPE TO DELIVERY AGENT>
The Problem
===========
First, allow me to show the last lines of /etc/procmailrc on the SMTP
/ IMAP server:
--- BEGIN EXCERPT ---
:0w:/var/tmp/$LOGNAME.lock
| /usr/imap/bin/deliver -m user.$LOGNAME
:0e
{
EXITCODE=$?
}
--- END EXCERPT ---
The IMAP mail system maintains per-mailbox quotas. If the user is over
quota when procmail tries to write to the pipe, a non-zero exit status
will be seen by procmail. When procmail exits, it hands off the exit
code to sendmail, which does what it should. (Sees the temporary error
and requeues the mail).
It ALSO writes to /var/mail/<USERNAME>, which is its concept of
DEFAULT. (I've tried changing DEFAULT to be a pipe to the delivery
agent - doesn't work.)
My questions
============
o Is procmail writing to /var/mail/<USERNAME> because it falls off the
end of /etc/procmailrc and still considers itself in a non-delivered
state? If so, isn't this contradicotry to the man page exceprpt:
Delivering recipes are those that cause header and/or body
of the mail to be: ... absorbed by a pro-
gram ...
Or perhaps ...
o Does an error in conjunction with the 'w' flag put procmail back in
a non-delivered state? The only thing I find in the man page for 'w'
and errors is:
if the filter is unsuc-
cessful, then the text will not have been filtered.
o I really need to tell procmail to NEVER EVER write to /var/mail. I
don't want to use the '-t' command-line argument to do this because
bounces will never be generated. Can the DELIVERED variable be used to
somehow do this? From the docs in the man page, I am uncertain. (Maybe
I'm hitting a mental block)
o Could someone suggest a rewrite of the above RC file excerpt, so as
to keep mail from ever getting written into /var/mail , especially
upon an error of the delivery agent?
Thanks. Sorry for the verbosity.
- Larry