At 04:26 2000-03-30 -0500, Marshal Benton wrote:
The sendmail config has the 2 following procmail lines.
Mprocmail, P=pathtoprocmail, F=DFMSPhnu9, S=11/31, R=21/31,
T=DNS/RFC822/X-Unix
A=procmail -Y -m $h $f $u
Where'd you pick up this config item? Looks like you have procmail defined
to act as an SMTP delivery agent (based on the 'x1' rulesets being used),
which I'm reasonably sure is won't work as. The flags are:
D Need Date: in header
F Need From: in header
M Need Message-ID: in header
S Assume specified uid and gid
P Need Return-Path: in header
h Preserve uppercase in hostname
n Don't use UNIX-style From in header
u Preserve uppercase for username.
9 Convert 7-bit to 8-bit if appropriate
All of these are not unusual flags for normal SMTP deliveries.
I'm prone to believe that this is the result of an errant MAILER(procmail)
in a sendmail M4 file because someone expected they needed it like
MAILER(smtp) and MAILER(local). If so, and unless someone more
knowledgeable says otherwise, I think that should be removed from your M4
-- the FEATURE(local_procmail) should be sufficient, unless there is a
specific reason you're doing this.
Mlocal, P=/pathtoprocmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30,
R=20/40,
A=procmail -Y -a $h -d $u
This definition is the standard "procmail as local delivery
agent". Nothing really special about this.
I have the following sample global pocmail filter.
# no $var changes (all defaults)
:o:
Should be a ZERO, not an OH.
* ^From:(_dot_)*user(_at_)domain
/backup/junk
If you're going to be using filters of these types, you might want to
consider using the access database feature of Sendmail (not to be confused
with "MS Access"), though that won't store the message - it'll reject it
during the SMTP transaction. That keeps you from even accepting the bodies
from individuals or domains you don't want ANYTHING from.
Keep in mind also that the regex of "*user(_at_)domain" will match addresses
which end with that - so if you were matching for "*smith(_at_)domain". then
"dave(_dot_)smith(_at_)domain", "rusty(_dot_)smith(_at_)domain", "blacksmith(_at_)domain" would all
match. If you're going to heave mail in a global fashion, be sure you're
not being too liberal about it.
The antispam/relaying support in Sendmail 8.10 is really quite nice -- you
might consider upgrading to that and enabling some of those rules (or
enabling the subset you have available within 8.9.3, though 8.10 is really
worth the effort).
BTW, you might check out the following:
<ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html>
1. What is the advantage/disadvantage of having a procmail
delivery agent and procmail as the local delivery agent? How will
they interact/conflict with each other.
I don't follow. As configured in the sendmail.cf, procmail is used as an
LDA = Local Delivery Agent. Procmail shouldn't be invoked for outbound
email -- last I was aware, procmail doesn't do a shred of SMTP.
2. A users ~/.procmail file takes priority over the system
procmail file. Can I have procmail use both? if so, how?
I don't know where you picked that up from -- if procmail is the LDA, the
global procmailrc should be processed, THEN the users'. Note that the
/etc/procmailrc is NOT a dot-file, whereas the user ~/.procmailrc IS.
This is easy to demonstrate: create an /etc/procmailrc and make it a filter:
#--
:0fh
|/usr/bin/formail -b -A"X-GlobalFiltered: YES"
#--
MAKE SURE THE /etc/procmailrc file is mode 744 or more secure. Actually,
since procmail-as-LDA should be running as root, you should be able to run
it as mode 400, thereby concealing the files contents from snoopy users.
The above filter would add a nonsensical X-GlobalFiltered: header to all
messages.
User-specific procmail rulesets should still execute, AND those messages
will have this new header in them. You could create a test user and a
basic filter rule to verify this.
3. Several users get long delays in mail delivery with
procmaill as the delivery agent. Mail works fine with
the _bin mail_ agent. The home directories are writable
by the owner only. There is no .forward or .procmail file.
Any ideas on the cause of the delays?
Possibly mailbox locking issues (are they retrieving messages via POP3 or
something?). If these users have their own procmail recipes, they may be
doing something funky. I have some really beefy filtering going on
(checking headers against a list of approx 200K domains), and I suffer
about a six second lag because the filters are so intense.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395