I have installed SCO Skunkware procmail 3.1.5 on a client's
SCO 5.0.7 Enterprise system to support installation of
spamassassin 3.1.4.

The problem: The users $HOME/.procmailrc is ignored if
/usr/local/etc/procmailrc file exists.

Details: SCO 5.0.7 Enterprise with MP5 as the only patch

Installation sequence:

procmail 3.1.5
spamassassin 3.1.4

perl Nakefile.PL and make fails as there is no C-Development system.

Install gngnutools5.0.7kj, and run perl Makefile.PL and make again
fails as the C-Development linker and support libraries are not installed.

Install linker and support libraries and try again.

This time perl Makefile.PL, make, make test, and make install run
and after copying my development .procmailrc and .forward to the
client's system and set up /usr/local/etc/procmailrc, and create
/usr/adm/sm.bin/procmail -> /usr/bin/procmail, and
/usr/lib/smrsh -> /opt/K/SCO/SendMail/8.11.0/bin/smrsh
spammassassin works but identified spam mail is delivered
to the settings in /usr/local/etc/procmailrc and ignores
the user's $HOME/.procmailrc.

When I delete /usr/local/etc/procmailrc, then spam is processed
according to the $HOME/.procmailrc settings.

My only previous experience with procmail and spamassassin was
when I installed them on my office system in preparation to
performing the installation on the customer's system.

My system SCO 5.0.7 with MP5 installed after SCO Development system.

One additional datum: I recompiled Skunkware source for Procmail 3.1.5
on my system and installed only the resulting procmail executable in
/usr/bin. I used custom to install the VOL distribution of Skunware
Procmail 3.1.5 to obtain the Man pages for procmail. I copied my
complied /usr/bin/procmail to the customers system and the
..forward and /usr/adm/sm.bin/procmail both reference the /usr/bin/procmail
and not the /usr/local/bin/procmail from the VOL distribution.

Anyone else notice a problem with a user's $HOME/.procmail not being
used when /usr/local/etc/procmailrc file exists?

Steve Fabac
S.M. Fabac & Associates