At 12:18 2006-05-10 +1000, Paul Matthews wrote:
I just wanted to say thank you for your help with the setup for my server.
If anyone is interested in what I did I've posted my finding on my website
http://www.yourhowto.org/content/view/65/9/
FTR, it's a good idea to specify in your writeup what versions of things
you were using. Some poor fool might stumble across your howto at some
point trying desparatley to get his installation working, but may have a
few older components (and may not want or be able to upgrade them
all). This is especially true of stuff for interoperating with software
from the Dark Kingdom.
But now I find that when someone sends a e-mail to a mailman mailing list
my server almost shuts down for 5 minutes, no one can sure the net or send
mail or retrieve mail.
This might seem like a totally asinine question, but it needs asking: have
you checked to see what processes are running and consuming resources?
I think it's procmail
(this statement is what makes me suspect you haven't checked to see what is
consuming resources when your machine drops to its knees).
... is there an option in procmail that I can say,
if the e-mail is going to mail-list(_at_)mydomain(_dot_)com don't Analise it?
I'm not familiar with mailman (IIRC, it is a postfix-specific list server,
which makes it rather unfriendly to use if you're not already married to
postfix), but most list servers operate via aliases, invoking the list
server software directly from the MTA when it recieves mail for the address
associated with a list. As such, the *LDA* (say, procmail installed as an
LDA) won't be invoked. The LDA is used when mail is being delivered to a
LOCAL USER. The LDA is not invoked for relaying or for program mailers...
If you're got some hack in place where your listserve alias is invoking
procmail to wrap spam filtering in before the list server, it's possible
you have a loop type condition going on there.
Your confidentiality disclaimer is a riot: basically, it's saying the
people at your organization who send mail are inept and prone to sending
mail to the wrong people. I'm certain you have a similar disclaimer on
your letterhead, for printed correspondance?
Basically though, if procmail is invoked with -a argument, then argument
will be available in the script as $1. A typical _sendmail_ invocation of
procmail as Mlocal (LDA) is:
procmail -Y -a $h -d $u
"-Y" is berkeley mbx format
"-a $h" is the aforementioned $1 variable, which is the _recipient_host_
"-d $u" sets the recipient (resolved local user, not the fqdn email address)
IOW, out of the box, no. You cannot always assume that your list address
is in the To: field of an email message either, so:
:0
* ^To:.*your_list_id
{
SWITCHRC=
}
isn't feasable. It'll work sometimes, and definatley NOT others.
How are you invoking procmail?
your postfix "mailbox_command = /usr/bin/procmail -t /etc/procmailrc" (see
step 15 in your writeup)
would seem to be valid only for _mailbox_ deliveries.
Your blurb (step 18) on /etc/skel/.procmailrc is curious. "DROPPRIVS=YES"
is only signficiant on procmailrc files invoked with elevated
privledges. That DOES NOT include a _user_ procmailrc file, for which the
skel file is used to create.
An /etc/procmailrc file is a dandy place to put the SA invocation (and
where one might put a DROPPRIVS=YES recipe) -- this would negate the need
to have a ~/.procmailrc file for each user. To allow users to opt out of
SA filtering, you could check for the existance of a file in their
homedir. What they do with flagged mail should of course be up to them
(the actual shuttling it to a Mail/junk folder might be appropriate for the
skel file, with the understanding that the directory needs to exist, and
the user should be advised that the file is being created and will continue
to consume disk space if left unmanaged).
I'm curious, what is the significance of the first five letters of your
test message subject/body (in step 40 of your writeup)? It happens to
match a model identifier for a particular Jaguar car
Note that if you have a lot of LOCAL recipients for messages which pass
through your mailman server, your setup would be invoking SA for *EACH*
*COPY* *DELIVERED* *TO* *EACH* *LOCAL* *RECIPIENT*. *THAT* could give your
CPU some grief. If you centrally (/etc/procmailrc/) invoked SA, you could
put some logic in there to id the list and go "oh, this is relaying through
our list for which the SA should have already been invoked" (assuming you
invoke SA on the front end of your list server, which would be a good idea,
though you might want to NOT insert SA headers into the message, because it
makes it ugly for remote recipients).
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail