|
Re: Configuration question: Procmail not responding
2001-12-19 16:27:08
At 11:52 2001-12-19 +0000, Os Tyler did say:
Sean, I appreciate your response, I know that what I'm asking leans to the
sendmail side, but it seems intertwined with procmail.
Rather depends on whether the error is with procmail or not, doesn't it?
I personally think you're going about the global filter stuff in the wrong
way. Lots of maintenance overhead. Read the following, but focus on what
I present at the tail end.
I have tried for some time to trigger Procmail from
/etc/procmailrcs/virthost1, to no avail.
n.b.: you're not "triggering procmail _from_" that file - your config below
clearly shows you're trying to run procmail with that file as an
argument. That is VERY different, even if you think they're the same.
I have this entry in /etc/mail/mailertable:
virthost1 procmail:/etc/procmailrcs/virthost1
1. That doesn't quite look like a valid mailertable entry (unless you're
screwing with the config file to obscure hostnames before posting here, in
which case you should realize that in doing so, you make assisting you that
much more difficult because of likely syntax changes during your
obfuscation step). See 19.6.14 in the *SENDMAIL* book.
"virthost1.example.com" perhaps ?
2. Even if the above were valid (and note that makemap won't complain), you
still need to have an "M" (mailer) declaration for procmail in your
sendmail.cfg (again, that's SENDMAIL.cf). I don't recall seeing you
confirm that you'd set this mailer up - or what the commandline args are in
that definition.
However Procmail is never processing any mail (sent to *(_at_)virthost1)
through the /etc/procmailrcs/virthost1. Nothing is written to the VERBOSE
procmail log.
It seems to me that Virtusertable is simply redirecting the mail to the
/var/spool/mail directory, and overriding any chance for
procmail/mailertable to process the mail.
What does your mailer log (not procmail, but your SMTP agent) say? Any errors?
Have you tried running sendmail in delivery test mode? The basic form is:
sendmail -bv someuseraddr(_at_)virtualhost1(_dot_)example(_dot_)com
But if you read up on SENDMAIL, there are more complete and interactive
diagnostics available using -bt, etc.
Here are more details:
After many hours, I decided to investigate sendmail.cf. I found portions
of ruleset Parse1 (the bottom half of ruleset 0) with comments referencing
virtuser and mailer table
Right, mailertable is handled in 0.
If you insist on doing this within sendmail, you might find it easier to
use virtusertable->alias to define a filter process for inbound mail:
[virtusertable.txt]
@virtualhost1.example.com filter_user
[aliases]
filter_user: "|/usr/local/bin/procmail -m /etc/procmailrcs/spamfilter.rc
real_user"
Then, for default delivery in your script, pass the message to:
:0
!$1
This is thoroughly untested, but since you're the one with the SENDMAIL
configuration problem, how 'bout you try it and tell us how it works?
filter_user and real_user would be unique account names associated with
each recipient (real_user is their real local username, while filter_user
is an intermediate alias created just for processing mail through their
domain) - If you wanted to delve into sendmail, I imagine you should be
able to pass the actual username to the script via a sendmail variable
(I've simply never tried - seems there's a chicken-and-the-egg syndrome
here that would require some further sendmail scripting).
Believing that virtuser was overriding mailertable, I moved the
mailertable portions of sendmail.cf ABOVE the virtuser portions.
Reordering mail rules isn't always such a good idea unless you really know
what you're doing. It's even worse if you're changing them on a live mail
host, instead of on an isolated test machine.
After hupping sendmail, I found that Procmail will now process mail
through mailertable /etc/procmailrcs/virthost1, AND it writes to the
VERBOSE log (sample below).
I humbly suggest that the problem you describe would exist if you were
launching _ANY_ program from your virtusertable configuration, so it
certainly isn't a procmail problem.
If I remove the last line of the Procmail recipe:
!ost2
(which forwards all mail sent to virthost1 to a local account)
Depends on what ost2 is defined to. Keep in mind that this runs the
message BACK INTO SENDMAIL.
what I would like to have happen is for virtusertable to process the To:
portion of the header and put the mail in the correct mailbox in
Bad idea. To: may not contain a local user at all. You need to use the
envelope data if you're going to do this. But that defines the original
reciepient address, not the looked up _local_ user (which, if sendmail is
left to it's devices, will resolve through your
mailertable/virtusertable/aliases again if you send it to sendmail).
/var/spool/mail according to the mappings in /etc/mail/virtusertable ...
instead, when I remove the !ost2, I get:
procmail: [19872] Tue Dec 18 19:40:35 2001
procmail: Assigning "SPOOLDIR=/var/spool/mail"
procmail: Assigning "SENDER=root"
procmail: Assigning "RECIPIENT=eddy(_at_)virthost1"
procmail: Executing "spamassassin,-P"
procmail: [19872] Tue Dec 18 19:40:52 2001
procmail: Incomplete recipe
Well, duh, the way you're describing it, you have just removed the ACTION
line. You've violated the syntax of a procmail recipe. Like pulling the
wheels off of your car and wondering why it won't go anyplace. Isn't it
nice that procmail TELLS YOU THIS ("Incomplete recipe") instead of just
barfing?
If you insist on continuing with this methid, in your script, for debugging
purposes, emit the setting of $DEFAULT:
LOG="DEFAULT is $DEFAULT
"
If that is a valid mailbox for the intended user, change your action line
(where you deleted it) to:
$DEFAULT
(and properly LOCK the delivery rule too, since you'd be delivering to a file)
If the message delivers to their mailbox, then procmail is working fine. I
would however suggest that you don't want to write directly to their
mailbox, since that would effectively block them from being able to run
their own procmail filters.
OTOH, if you forward it back into the MTA (unless using the virtuser+alias
technique I described above), sendmail is going to go weird on you.
I want to use spamassassin, but I want to allow individual domains to
switch it on or off, whatever their preference. I'm already handling all
mail through virtusertable, and would rather not try to transfer all of
the information in virtusertable over to individual
/etc/procmailrcs/virthost files.
I've got to wonder why you don't just use an /etc/procmailrc file and have
it refer to a simple (or otherwise, if you so choose) database - no mucking
about in the mailertable or virtusertable.txt files:
[/etc/procmailrc/]
# this filter is run only for _some_ users
:0
* ? grep -qi ^$LOGNAME$ /etc/procmailrcs/spamassassin.users
{
# your spamassassin stuff
}
Then, add the recipients to spamassassin.users (as the local
usernames). Since the grep operation (which you _might_ want to hardcode
the path for, to eliminate path recursion for) anchors the search to
beginning and end of line, partial matches wont' occur - it's an all or
none affair (user "joe" being checked wouldn't score a hit because user
"joebob" elected to use the service).
This of course means that any given _user_ elects to have their mail
filtered - if they have multiple domains -- they can't do one domain but
not another. Anything which takes final delivery to that user WILL be
filtered if they've subscribed to the filters. Even local mail. However,
it won't filter for mail which is forwarded along either via an explicit
forward in the virtuserable or aliases file, or which is processed with
Mprog (vs. Mlocal).
Besides the simplicity of this (though there IS added overhead for each
inbound message invoking the grep to check - it'd be spiffy if procmail had
internal file hashing capability), it also means that since you don't have
to tweak the sendmail config files (mailertable and virtusertable) for each
user, the spanassassin.users file could be managed via a web administration
applet on your server (user signs in with full authentication via https,
then clicks a box saying they want in or out of the filter - back end
rebuilds the data file (or instead of using grep, you use a perl/c++
program that uses a hash db). Alternatley (or in addition), users could
run a local program which performs the update.
Even if you don't provide a chooser facility to your users, your own
administration of that _one_ flat file will be a lot easier.
You could take it a step farther and have multiple columns (or fields, if
using a db) in the file (would require a change to the grep, but nothing
severe), and allow people to sign in and out of various filters, rather
than just this one (or the whole lot of whatever you employ).
FILTER_OPTIONS=|`grep "^$LOGNAME " /etc/procmailrcs/spamassassin.users`
:0
* $FILTER_OPTIONS ?? [ ]ASSASSIN\>
{
# do your thing
}
# repeat the basic ruleset structure for other selectable rulesets, making
# use of the already defined $FILTER_OPTIONS.
The users file would look like so:
username ASSASSIN SPAMGOOP BULKMAIL
joe ASSASSIN BULKMAIL
joebob SPAMGOOP
Want to guess as to which way *I* would approach this if I were contracting
for your employer and wanted to provide a versatile solution?
[snip - previous message, not needed if you're not replying point by point]
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
|
|