At 22:32 2003-02-09 +1300, Roland Hill wrote:
Feb 9 22:10:50 rrl03 postfix/local[2657]: 4DA68703CE:
to=<onepop(_at_)localhost(_dot_)monaro(_dot_)local>, relay=local, delay=0,
status=bounced
(can't create user output file. Command output: procmail: Missing action
procmail: Missing action procmail: Missing action procmail: Incomplete
recipe )
Error messages are explained in 'man procmail'.
:0
* ^TO_rnrhill\+roland@
* !roland
flags start with ':'
conditions start with '*'
actions start with a mailbox path, a ! (forward), or a pipe '|' to a
program. Alternatley, you can enclose actions in braces '{}'. So, what's
your recipe above (and all the ones that followed it) do? Parse it by
reading the tokens to yourself off out loud.
I'd just tell you, but trust me, learning the self-diagnostic procedure
will be of a much bigger benefit.
onepop: "|/usr/bin/procmail -m /etc/procmail/onepop.rc"
Well, since you saw the logging, we can figure this was invoked correctly.
PLEASE consider placing a README file in the /etc/procmail/ dir that
reminds yourself that *THIS* directory has no special meaning to procmail,
unlike /etc/procmailrcs/. It'll save yourself some grief downline when you
might forget that.
Finally, a point of clarification, am I right in assuming that the ^TO_
expression won't pick up BCC'd messages, hence why this list passes by
the above recipes?
^TO_ will pick them up certain headers of your message contain references
to the BCC'd address. Your MTA (or your ISP's MTA, and fetchmail) may not
be inserting those references.
This relates to that bit I mentioned about "troubles with using a single
POP mailbox to operate multiple virtual users". More specifically, the
X-Envelope-To (and perhaps even the Received:...for) won't necessarily
appear in the headers if the message was addressed to multiple users at
your site. Procmail is a widely-used tool, so it wouldn't be a huge leap
to expect that your ISP may have another user subscribed to that list, and
thus when the message arrives at your ISP (before your fetchmail process),
the additional recipient information doesn't make its way into the headers
_BECAUSE_ there were multiple recipients there.
For instance, the copy of your message which I received from the list
included the following:
Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE
[134.130.3.130])
by trei.professional.org (8.10.2/8.11.1) with ESMTP id h199WNo23691
for <PSE-L(_at_)mail(_dot_)professional(_dot_)org>; Sun, 9 Feb 2003
01:32:23 -0800
X-Envelope-From: procmail-admin(_at_)Lists(_dot_)RWTH-Aachen(_dot_)DE
X-Envelope-To: <PSE-L(_at_)mail(_dot_)professional(_dot_)org>
The last two, I have configured my MTA to add. Other MTAs sometimes use
other headers (Apparently-To: for instance, or Delivered-To:) for the same
purpose.
Run 'man procmailrc', then search (the following keystrokes):
/ (starts search)
\^TO_ (\ escapes the ^)
[ENTER]
There, you'll find that ^TO_ is expanded to the following:
`(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope
|Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)'
You _could_ expand upon this to check the _Received_ headers, and for
Delivered-To:
BIGTO="(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope\
|Apparently(-Resent)?|Delivered)-To):(.*[^-a-zA-Z0-9_.])?)"
(note that the continuation lines _MUST_NOT_ contain leading whitespaces,
as they'll be interpreted literally, unlike within a continued _condition_
line in a recipe)
:0:
* $ ${BIGTO}youraddress
somemailbox.mbx
Note that the syntax for the macro isn't quite the same - procmail
pre-defined "^TO_", and so it isn't invoked as a variable. To expand a
variable as a regexp, you need the above condition syntax.
To expand that to catch the possible appearance of your address within the
Received: header, try:
:0:
* $ (${BIGTO}|^Received:.*for\>+<?)youraddress
somemailbox.mbx
That should be pretty serviceable. As I said, there are issues doing what
you're trying to do with one POP mailbox. The bottom line though, is if
you don't spot your email address in any of the headers, it's going to be
pretty difficult to peg it as being delivered for you. At a minimum
separate POP mailboxes (whether maintained at your ISP, or handled locally
through an SMTP connection) is he only consistent way to get your messages
deposited into a mailbox for a specific user - the MTA doesn't always pass
along all the envelope data (which isn't really part of the headers).
You should check out the disclaimer link that is in my .sig -- from there,
you'll find some information on my procmail 'sandbox' recipe testing setup,
which will dramatically improve your ability to self-diagnose scripts, and
test most things without subjecting your live email to the mix.
---
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