Subject: [[email-masked]: Re: beginner help]

From: [email-masked] (Steve Morris)
Date: Mon, 18 Jul 94 10:35:52 EDT

David,

Thanks for your response below. You pointed out two mistakes which I
have corrected. However it seems to me that the mistakes cause extra
behavior but should not prevent the behavior that I was expecting, namely
a reply message when the conditions match.

The .forward problem ment that mail was accumulated in the mailbox in
addition to going to procmail. The .procmailrc problem ment
that mail from the invalid id YOUR_USERNAME would not get the reply.
(I had blithly assumed that YOUR_USERNAME (like FROM_DAEMON) was a special
key word.)

It seems to me that I should still have gotten the reply in spite of
these mistakes. I must be doing a third thing wrong but I can't see it.

I was also intrigued by your dangling second possibility. What DOES procmail
do if there is no match? I don't see this case mentioned in the man pages.

Is there some audit trail or logging capability which I can turn on
to track things down?

Regards,

Steve Morris

******************************************************************
you wrote:

>Steve Morris wrote,
>
>| I am having problem getting started. I have built and installed without
>| problem but don`t know how to setup the .forward. I want to use procmail
>| to process the mail from my uid, i.e. I am not using it as the system
>| mailer. I'm pretty light on general mail experience.
>| 
>| I started with an example from the procmailex man page. I am playing with
>| a test account so I don't screw up my mail. The problem is that I send mail
>| to testid with contents retrieve and it ends up in the testid mail with
>| out any processing.
>
>| *******************.forward contents ***********************
>| 
>| \testid, "|/users/sjm/bin/procmail"
>
>OK, let's start there.  That .forward has two addresses in it, so the mail
>delivery agent (sendmail or whatever) makes two copies of every incoming
>letter.  One goes to \testid, which, because it has the backslash, means
>straight to testid's mail spool regardless of what testid's .forward says
>(you have to do that or it would loop forever).  The second copy is fed
>to procmail.  Procmail reads testid's .procmailrc, which Steve said looks
>like this:
>
>| ******************* .procmail contents *********************
>| 
>| :0
>| * !^From +YOUR_USERNAME
>| * !^Subject:.*Re:
>| * !^FROM_DAEMON
>| * ^Subject:.*retrieve
>| | (formail -r ; echo filter test) | $SENDMAIL -oi -t
>
>Now, one of two things will happen: either an incoming letter will fail
>one of those four conditions (or, since the first three test for failure,
>perhaps I should say "pass one of the first three or fail the fourth")
>or it will meet all four (i.e., fail the positive parts of the first three
>and pass the fourth).  Since Steve didn't replace "YOUR_USERNAME" with his 
>own user
>
>
>David W. Tamkin  P. O. Box 3284  Skokie IL  60076-6284
>[email-masked]   MCI Mail: 426-1818   +1 312 714 5610

---

From: [email-masked] (David W. Tamkin)
Date: Mon, 18 Jul 1994 13:15:59 -0500 (CDT)

I hate nvi.  It is a punishment from Satan.  Thanks to its bugs, my first
draft went out incomplete, and Steve did his best to garner what he could
from it.  I sent a completed version, but it vanished; it never bounced back
to me from the list either.  So, let's finish what I tried to say Sunday
night about Steve Morris's testid account:

| >| *******************.forward contents ***********************
| >| 
| >| \testid, "|/users/sjm/bin/procmail"

[I explained Sunday night why having "\testid" leaves a copy in the spool,
 and Steve understands that now.]

| >| ******************* .procmail contents *********************

There lies one big problem I didn't notice Sunday night: Steve seems to have
named the rcfile ~testid/.procmail instead of ~testid/.procmailrc.  He didn't
specify ".procmail" on the command line in .forward, so procmail finds no
file named .procmailrc, assumes there is no rcfile, and delivers to $DEFAULT.
That should make two copies in the main spool file.  (I'd be highly surprised
if sendmail could still optimize at that point and reduce them to one.)

| >| :0
| >| * !^From +YOUR_USERNAME
| >| * !^Subject:.*Re:
| >| * !^FROM_DAEMON
| >| * ^Subject:.*retrieve
| >| | (formail -r ; echo filter test) | $SENDMAIL -oi -t

And in the middle of the next paragraph nvi failed on me, so the rest of the
second version, which completed it all, I now have to retype.  Fun.

Let's say that procmail sees that recipe: Steve (1) renamed .procmail to
.procmailrc, (2) named .procmail as the rcfile on procmail's command line
in the .forward pipe, or (3) had called the rcfile ".procmailrc" all along
but just made a mistake when he wrote to the list about it.

An incoming letter, besides being filed in testid's spool because '\testid'
is in .forward, will either meet all four conditions or fail at least one of
them.  If it meets all four, procmail will run the action line on it.  That
action line reverses the header into a reply, drops the original body (no -k
option used on formail), adds the words "filter test" where the body was, and
sends the result back to the sender.  There is no 'c' flag on the recipe, so
procmail has done its job and exits.

[Three of the conditions are negated, so when I speak of passing or failing
 them, I mean passing or failing the negated versions, i.e., respectively
 failing or passing the positive part after the exclamation point.]

If the incoming letter fails at least one condition, procmail will continue;
it has reached the end of the rcfile, so it assumes this recipe:

  :0:
  $DEFAULT

and it should deliver a second copy to testid's mail spool.  Now, if Steve
finds only one there, maybe there is a locking conflict and one copy clobbers
the other.  Certainly, what with "YOUR_USERNAME" in the recipe instead of
"sjm", all of his test letters as of Sunday would have met the first condi-
tion.  (I think Stephen [van den Berg] intended YOUR_USERNAME for the case of
sending test letters to oneself, and it's "testid", not "sjm", that belongs
there anyway.)  Unless Steve is writing from root, !^FROM_DAEMON should be
satisfied as well.  I'll gather that he is not sticking "Re:" into the sub-
ject line, so that satisfies the third condition.

The fourth condition is the puzzler.  Steve's original question said that he
sent "mail with contents retrieve to testid."  If the word 'retrieve' is not
in the subject line but in the body, the fourth condition will fail and proc-
mail will not execute recipe's action.  The recipe would need the 'B' flag to
search the body (actually 'HB' because the other conditions require egrepping
the header) for the word "retrieve". 

We really need to know more: do Steve's test letters have the word "retrieve"
in the body or in the subject line?  Did he name the rcfile ".procmail"?
Are two copies of each test letter showing up in testid's spool or only one?
He did say that he isn't getting the acknowledgments back.

After reading my prematurely aborted first draft, Steve wrote further:

| It seems to me that I should still have gotten the reply in spite of
| these mistakes. I must be doing a third thing wrong but I can't see it.

That's what I was trying to say when my first draft went out incomplete,
what I was trying to say when my second draft vanished, and what I hope
is finally coming through now.  This time I'm keeping a copy.

| I was also intrigued by your dangling second possibility. What DOES procmail
| do if there is no match? I don't see this case mentioned in the man pages.

Sorry; it wasn't intended to dangle.  That was in the complete version of my
response and you can find it here about forty lines back.

| Is there some audit trail or logging capability which I can turn on
| to track things down?

Emphatically yes.  Check out the LOGFILE and VERBOSE variables in the man
pages for procmail(1) and procmailrc(5).  Name a logfile and you'll get
error messages and a record of final disposition; specify verbose logging
and you'll get all the information you could possibly want.