At 12:18 2003-12-05 -0600, stucker(_at_)tacticallysound(_dot_)com wrote:
Hi,
This is my first post to the list, thank you for having me.
I am seeking some help with Procmail, and this looks like the best place to
get it.
Please excuse my ignorance, and thanks for any help I get.
I am using Procmail to pipe mail through spam assassin, filter for
attachment types, and handle a couple small other things. I am getting some
errors that I don't understand and I am also having some problems with
understanding how Procmail/Sendmail handle entry's in the virtusertable for
my email aliases and virtual domain email.
Procmail doesn't do anything with virtusertable (or even aliases). That's
an MTA thing. Procmail is invoked either for local delivery (after the MTA
has resolves virtual/aliases) or explicitly in an alias.
the original email. Spam assassin is working, at least for real accounts
(not virtual aliases).
"virtual aliases" being? Accounts delivered to ELSEWHERE? If they're not
LOCAL, or the delivery sets up a delivery to FILE, rather than a USER, then
they're not going to invoke anything.
fully understand Procmails flags, or some of the syntax.
Then tread carefully when implementing new filters that affect all mail on
the system. Set up a sandbox (see my .sig) to test filters, or set up a
separate testing host and throw loads of clones messages at it.
The second issue I have is how do I get Procmail to filter virtual address's
(if it's even possible). It seems that when sendmail is done processing the
virtual address, Procmail never even sees it unless the alias in the
virtusertable points to a local account. This is probably because Procmail
is the local delivery agent and only gets invoked on local deliveries eh?
Right-on.
Is there anyway to force procmail to scan all email that passes through the
system, not just email that is local? (I want to pipe all mail through the
attachment filter and spamassassin for my clients, even mail aliased to
another system i.e.: user(_at_)mydomain(_dot_)tld sent to
user(_at_)theirdomain(_dot_)tld)
You have to have an intermediate local alias, or invoke the filters from
within MTA-defined delivery rules (which can be ugly).
An example aliasing:
[virtusertable]
@userdomain.tld userdomain.alias
[aliases]
userdomain.alias "|/usr/local/bin/procmail -m
/etc/procmailrcs/remotemail.rc userrealaddress(_at_)otherdomain(_dot_)tld"
Then have the rcfile do whatever, and use $1 as the address to forward
to. Be careful that you're not doing this for addresses which ultimatley
deliver locally, since you could be setting yourself up for a loop.
Finally, what is wrong with my recipe that I get the weird spamassassin
error? "Cannot write to /dev/null/.spamassassin/user_prefs: Not a
directory". Does this look like a Procmail error or a Spamassassin error?
Obviously it can't find /dev/null as a directory, but why is it even looking
there?
SA error - it's obviously an SA file, and the filename appears NOWHERE in
your procmailrc.
PMDIR=/etc/Procmail
FTR, /etc/procmailrcs is a special dir for procmail, /etc/Procmail is
not. Is there some significance to you having what appears to be a global
rc config that isn't in a standard location?
#Handle bug in procmail that drops the F from the from header for some
reason
Only an issue if you have this problem. Methinks if someone is actually
seeing this problem in a reproduceable fashion, it'd be handy to
communicate the details to the procmail-dev folks, so the irritating thing
can be tracked down.
Suggestion for the future: you should seek to diagnose problems long before
you have so many of them. Additionally, this stuff should be checked in a
sandbox, not on a live mail system.
/bin/bash: -AX-Loop: adminstrator(_at_)domain(_dot_)tld: command not found
See below.
procmail: Error while writing to " (formail -r \
-i"Subject: Returned email: Restricted attachment" \
-i"From: EmailSystems(_at_)domain(_dot_)tld" ; \
-A"X-Loop: adminstrator(_at_)domain(_dot_)tld" ; \
echo "MEANINGFULL ERROR" ; \
| $SENDMAIL -oi -t"
Where's the closing parenthesis on that formail|sendmail ? Also, the
semicolon terminates the command and chains another. so to the shell, the
formail invocation stops after the -f"From:..." bit, and -A"X-Loop" is a
wholly separate command. Additionally, no ';' is necessary between a
command and a pipe.
Rewritten, the offending recipe would be something like:
{
:0c: zipfilter.lock
| (formail -r \
-i"Subject: Returned email: Restricted attachment - message.zip or
readnow.zip" \
-i"From: EmailSystems(_at_)domain(_dot_)tld" \
-A"X-Loop: adminstrator(_at_)domain(_dot_)tld" ; \
echo "MEANINGFULL ERROR" ) \
| $SENDMAIL -oi -t
#Throw the original email message in the bit bucket
:0
/dev/null
}
Note that if you're going to discard the message, there's absolutely no
need for the 'c' flag. OTOH, if you want to discard the message EVEN IF
there's a problem with the formail-sendmail delivery, then you might
legitimatley keep the discard recipe there (thought the comment should be
revised to indicate that it is there for this purpose). But definatley
lose the 'c' flag - it's just adding additional overhead.
procmail: Match on "^Content-Type: multipart/.*"
procmail: No match on "^Content-(Type|Disposition):
.*;.*($.*)?name=.message|readnow*\.(zip)(")?$"
procmail: Extraneous locallockfile ignored
This is caused by having something like:
:0:
* condition
{
:0:
* other condition
action
}
As you have with the recipe block which has that same regexp in the outer
level. you're double-locking - the outer level has no FILE to lock with,
and the inner level (which is actually delivering to a file, has a lock
being specified.
procmail: Executing "spamassassin"
Cannot write to /dev/null/.spamassassin/user_prefs: Not a directory
Failed to create default user preference file
Well, that is an an SA problem. Looks like SA is being told to write prefs
to /dev/null, and it's tacking on a filename. Perhaps set something up in
/tmp instead for a bit to see if that resolves it, then set up a special
user directory for SA if it does and change that SA setting to that dir?
---
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