procmail
[Top] [All Lists]

Re: Procmail help request with recipe and errors.

2003-12-05 13:11:21
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

<Prev in Thread] Current Thread [Next in Thread>