The script is :
[script deleted because my mail client would mess it up]
So it isn't a filter, and that `f' flag in the old code was a mistake.
I guess so, yea. That might explain some oddness I saw in the
/var/mail directory and the procmail log.
You had something like /home/$LGONAME in the original post, so I thought
that was each user's home directory. You could compile procmail to use
/home/$LOGNAME/.procmailrc (or whatever it was) as the default rcfile
for each user.
My bad. Yes, I did a bad thing there. Actually, the users home
directory on every entry is /nonexistant, and the documentation it says
the /etc/passwd entry is needed for procmail file locking, which I don't
get since the directory doesn't exist, and if its doing locking in /var/mail,
it really doesn't matter I'd think since it isn't used by the cyrus stuff.
If /bin/test exists and is either an executable binary or an executable
hash-bang script, procmail won't need to invoke a shell. But let's say
it does (if not, drop the semicolon) ...
* ! ? test -f /usr/local/etc/procmailrcs/$LOGNAME ;
| /usr/local/cyrus/bin/procmail-cyrus-delivery.sh $LOGNAME
# privileges have been dropped, so it's safe to SWITCHRC
I dropped the semicolon for grins and giggles sake, and it appears
to be working properly.
I'm assuming that the compiled-in value of DEFAULT is sane in case test
passes and SWITCHRC fails.
Well, not sure how to say this. Its MILDLY sane. The /var/mail
directory exists, but once mail dropped into it it couldn't be accessed
using the IMAP.
If you don't mind an error message when the individual rcfile is
nonexistent or unusble, you can do this and avoid running test (or a
shell for it if it needs a shell):
(I mind. :) )
This is looking very promising. This along with my running a
sendmail on a different port, then telling procmail to use a non-default
rc, I can really test this out well!
Much appreciated, Tuc
procmail mailing list Procmail homepage: http://www.procmail.org/