Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- From: "Steve M. Fabac, Jr." <smfabac@xxxxxxx>
- Date: Wed, 23 Aug 2006 15:58:54 GMT
Boyd Lynn Gerber wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I downloaded procmail 3.1.5 Skunware VOL's and installed it
on my SCO 5.0.7 with MP5.
I extracted the .forward recommendation from "man procmail"
"|IFS=' '&&p=/usr/local/bin/procmail&&test -f $p&&exec $p -Yf-||exit 75 #smf"
I use in my .forward
- ---------------------Cut-Here----------------------
| /usr/local/bin/procmail
- ---------------------Cut-Here----------------------
Thanks Boyd.
That helps a lot. After I posted the original message, I noticed in
/usr/adm/syslog:
7:38:46 unix sendmail[4767]: k7N7ck104764: SYSERR(smf): Cannot exec /usr/lib/smrsh: No such file or directory
So I looked for smrsh and found it in /usr/bin but not in /usr/lib.
Running custom -> verify system -> symlinks failed to fix the problem
so I manually created the link in /usr/lib:
# cd /usr/lib; ln -s /opt/K/SendMail/8.11.0/bin/smrsh smrsh
# ls -l /usr/bin/smrsh smrsh | less
lrwxrwxrwx 1 root root 36 Sep 2 2004 /usr/bin/smrsh -> /opt/K/SendMail/8.11.0/bin/smrsh
lrwxrwxrwx 1 root sys 36 Aug 23 03:56 smrsh -> /opt/K/SCO/SendMail/8.11.0/bin/smrsh
Then the error in /usr/adm/syslog changed to:
Aug 23 08:56:25 unix smrsh: uid 200: attempt to use IFS=' '&&p=/usr/local/bin/procmail&&test -f $p&&exec $p -Yf-||exit 75 #smf
I then tried your .forward above:
| /usr/local/bin/procmail
And the error in /usr/adm/syslog changed to:
Aug 23 09:22:16 unix smrsh: uid 200: attempt to use procmail
I checked the man page on smrsh and it indicated directory /usr/adm/sm.bin
for programs you want to allow sendmail to run. So I checked and there
is no /usr/adm/sm.bin on my systm. I created it and placed the following
in it:
# cd /usr/adm/sm.bin
# ls -lt
total 0
lrwxrwxrwx 1 root sys 23 Aug 23 09:53 procmail -> /usr/local/bin/procmail
Now, my simple .procmailrc is working and test mail is being delivered to
my /usr/spool/mail/smf inbox instead of bouncing.
Ooops, not so fast. Procmail is now corruping my /usr/spool/mail/smf mailbox:
# mail -f /usr/spool/mail/smf
The mailbox "/usr/spool/mail/smf" is not in a consistent format.
It appears to be in configured format followed by the old format.
You can do one of the following:
1 Convert the mailbox to the old format
2 Convert the mailbox to the configured format
3 Ignore the format and try to continue
4 Quit the operation
If you are unsure, quit and ask your mail administrator for help
Which would you like to do (1,2,3, or 4)?
I went back and tried the original .forward file:
and I see in /usr/adm/syslog:"|IFS=' '&&p=/usr/local/bin/procmail&&test -f $p&&exec $p -Yf-||exit 75 #smf"
Aug 23 15:02:17 unix smrsh: uid 200: attempt to use IFS=' '&&p=/usr/local/bin/procmail&&test -f $p&&exec $p -Yf-||exit 75 #smf
So SCO's implementation of Sendmail 8.11.0 requires placing something else in
/usr/adm/sm.bin to allow the complex .forward construct to work.
And I still need suggestions on how to prevent procmail from hosing my
mail box.
Also, I note that the times logged in /usr/adm/syslog looks to be GMT rather
than local.
Well looks like procmail is now working with your simple .forward file and
the next thing to do is get Spamassassin 3.1.4 to work. I'll try your .procmailrc
and modify it as required for my system and report back how it works.
PS I had checked with Roger Cornelius based upon his last post
on Spamassassin and he responded:
Roger,
I need to get Spamassassin working on 5.0.7. Will you please send me
your recipe for getting this done?
As I noted in that thread, I was never able to get it working. I was
able to build it and run the tests, but never figured out how to
integrate it with sendmail. The documents I cited at the URL above
implied it couldn't be done without libmilter support in sendmail
- something the OSR507 sendmail didn't have. I haven't tried to get it
working since then, but MP5 includes a new perl, so building your own
perl may no longer be necessary.
Well I just retrieved the latest spamassassin (3.1.4) and it builds
OK and all but 4 tests (ones not auto-skipped) pass on my 507 box with
MP5 installed. No local build of perl was necessary. Some optional
modules are missing (the cause for the skipped tests), so you might want
to download/install those. You'll still have the problem of integrating
it with sendmail though. If you're using an MTA other than sendmail, it
may be possible to get it working. There are docs on integrating with
different mailers at the above URL.
To build, I did:
perl Makefile.PL
make
make test
I didn't go so far as installing it. Good luck.
That's what started me looking into procmail as it is hinted
at in the INSTALL file in the Spamassassin 3.1.4 tar ball.
I'll post back any success I have with Spamassassin.
and .procmailrc (also copied out of man procmail ) as:
- ---------------------Cut-Here----------------------
#
# Vars
#
SHELL=/bin/sh
MAILDIR=$HOME/Mail
DEFAULT=$MAILDIR/Unsorted
#LOGFILE=$MAILDIR/procmail.log
LOGFILE=$MAILDIR/Logs/procmail.log
LOCKSLEEP=0
SUSPEND=0
COMSAT=no
COMMITS=$MAILDIR/Commits
VERBOSE=off
# This rule simply kills all the mails with windows executable in the
# attachment If you're expected to receive legitimate *.exe files and
# cannot ask the sender to send them as *.zip or whatever do not use this
# rule
:0 B
* ^Content-Type:
(application/octet-stream|audio/x-(wav|midi));$?.*name=.*\.(exe|pif|bat|scr)
/dev/null#
## Redirect common virus attachments inc. zipped versions
:0 B
*
name=.*(document|readme|doc|text|file|data|test|message|body)\.(vbs\"|wsf\"|
vbe\"|wsh\"|hta\"|scr\"|pif\"|exe\"|shs\"|bat\"|bas\"|cmd\"|zip\")
{
:0
/dev/null
}
# This rule matches the header of all windows executables.
# It does not rely on .exe extension, but matches the b64 encoded header.
# A windows executable allways starts with the letters MZ och ZM.
# Since I live in a Microsoft free home I can safely throw away all of
# them, if you don't you might want to put them in a separate mailbox for
# later scanning with a virus scanner!
:0 BD :
* ^(Wk|TV)..............//
/dev/null
# All mail from tps@xxxxxxxxxxxxx
:0
* ^From: .*tps@xxxxxxxxxxxxxx
/dev/null
#########################################################################
#
# send all email through spamassassin
#
:0fw
*
| $LOGNAME/Mail/mail-check
# | $USER/Mail/mail-check
# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
#$HOME/Mail/spam
#:0:
#* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
#* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*
#$HOME/Mail/spam
# All mail tagged as spam (eg. with a score higher than the set threshold)
# is moved to "probably-spam".
:0:
* ^X-Spam-Status: Yes
$HOME/Mail/probably-spam
#
# BK $COMMITS - slag
#
:0
* ^List-ID: .*bk.slag*
$MAILDIR/ZENEZ/slag/dev-public
#
# ZENEZ commits lists
#
:0
* ^(To|Cc): .*slag-commits@xxxxxxxxxxxx(com|org|de)
$MAILDIR/ZENEZ/SLAG/commits
#
# MySQL internals lists
#
:0
* ^(To|Cc): .*internals@xxxxxxxxxxxx(com|org|de)
$MAILDIR/MySQL/myint
# Send all other mail to Incoming Mail Box
:0
*
/usr/spool/mail/$USER
# Send all other mail to Incoming Mail Box or forward
#:0
#! user@xxxxxxxxxx
- ---------------------Cut-Here----------------------
But when I send a test e-mail (or any email) to smf I get:
# mailq
/usr/spool/mqueue (1 request)
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------------
k7N7ck104764 16 Wed Aug 23 07:38 smf
(Operating system error)
"|IFS=' '&&p=/usr/local/bin/procmail&&te
So either the examples in the procmail man page are wrong for SCO 5.0.7
or something else is wrong.
Can anyone suggest how I debug this problem? Trying to dope out how to turn on
verbose mode from the description in the procmail man page is a study in
frustration: Once again a man page written by someone who knew what they
knew, but didn't know how to tell a novice the things they needed to know:
Extended diagnostics can be turned on and off through set-
ting the VERBOSE variable.
[pid] time & date Procmail's pid and a timestamp.
Generated whenever procmail logs a
diagnostic and at least a second
has elapsed since the last times-
tamp.
Acquiring kernel-lock Procmail now tries to kernel-lock
the most recently opened file (de-
scriptor).
Assigning "x" Environment variable assignment.
Assuming identity of the recipient, VERBOSE=off
Dropping all privileges (if any),
implicitly turns off extended diag-
nostics.
I've worked with UNIX for 20+ years but this is too cryptic for me.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
- --
Boyd Gerber <gerberb@xxxxxxxxx>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQFE7DCuVtBjDid73eYRAmtCAJ9PhZcRsHw5MhV+aeerzciRAv9YMwCfQu7P
JzD5TOH0abx2coutoPMaMfo=
=PBdx
-----END PGP SIGNATURE-----
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
.
- Follow-Ups:
- Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- From: Boyd Lynn Gerber
- Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- References:
- Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- From: Steve M. Fabac, Jr.
- Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- From: Boyd Lynn Gerber
- Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- Prev by Date: Re: LP command syntax question
- Next by Date: Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- Previous by thread: Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- Next by thread: Re: Problem with Skunkware procmail 3.1.5 & 5.0.7 MP5
- Index(es):
Relevant Pages
|