procmail
[Top] [All Lists]

Re: Script problem - "skipped" and store/forward problems

1996-04-30 13:03:57
PSE(_at_)netcom(_dot_)com (Professional Software Engineering) writes:
...
The system is running Procmail v3.11pre3

I'm trying to get a SIMPLE maillist function working (and do a couple 
of other things), and it seems everything is working against me.  And 
of course, so far as I know, the only way to test this is to put it 
into place, which is a bit troublesome since it affects my regular mail 
distribution.

I'm not sure I'd call this a "SIMPLE maillist function".  To me, simple
implies it fitting inside my .procmailrc, in less than one (67 line)
screenful.

As for it affecting your regular mail, put the following right before
the mailing list rules:

:0 c:
$DEFAULT

DELIVERED = yes

That should result in it being delivered into your default mailbox,
then your mailing list stuff will run.  Anything that falls out the
bottom will be tossed, which is fine as the above has already save a
copy.

Note that putting an explicit ":0\n$DEFAULT" at the bottom of you
.procmailrc only has an effect if you are setting DELIVERED.  Since
you don't currently do that, you should remove that last recipe.


In some places (in rule expressions especially), variables don't seem 
to expand, which it a bit annoying.  I ran into this before, and I gave 
up on it and just coded the strings I was searching for all over the 
place.

Variables only expand in conditions ("rules"?) when they start with
'$'.  But you correctly do that in one of the recipes, so...


but the messages never get forwarded.  They show up in the mailbox 
though.  I set VERBOSE on, and check the log, and I get the following:

These are the results of the log when I set VERBOSE on and send a 
message to PSE(_at_)professional(_dot_)org (the default mail case handled at 
the 
very end); my comments are indented:




procmail: Assigning "INCLUDERC=/home/pse/.procmail/boxes.rc"
procmail: No match on "^From:.*root"
procmail: No match on "^Subject:.*Flame"
procmail: No match on "^Precedence:.*bulk"
procmail: No match on 
"(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-
To):(.*[^a-zA-Z])?)KOlson"
   [snip - many more of these, which are expected]
procmail: No match on 
"(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-
To):(.*[^a-zA-Z])?)ixa-list(_at_)professional(_dot_)org"
procmail: Locking "/home/pse/temp/Default.lock"
procmail: Executing "/usr/sbin/sendmail,PSE(_at_)ix(_dot_)netcom(_dot_)com"
   [WHY is there a COMMA?  I've tries putting the address in quotes,
   adding spacing between it and the bang (!) forward command, no
   luck]

When logging the commands that it executes, procmail uses commas to
separate what it interpreted as the arguements.  This allows you to
see if what you thought should be two arguments were passed in as one.
In the above, procmail effectively did:

        execl("/usr/sbin/sendmail", "/usr/sbin/sendmail",
                "PSE(_at_)ix(_dot_)netcom(_dot_)com", (char *)0);

(the first is duplicated to provide both the path and argv[0])


procmail: [11632] Fri Apr 26 13:07:52 1996
procmail: Assigning "LASTFOLDER=/usr/sbin/sendmail 
PSE(_at_)ix(_dot_)netcom(_dot_)com"
   [Note here, no comma...]

commas are only for the log, not for LASTFOLDER.


procmail: Unlocking "/home/pse/temp/Default.lock"
procmail: Assigning "LASTFOLDER=/home/pse/Mail/mbox"
procmail: Opening "/home/pse/Mail/mbox"
procmail: Acquiring kernel-lock
From PSE(_at_)ix(_dot_)netcom(_dot_)com  Fri Apr 26 13:07:50 1996
Subject: testing.
 Folder: /home/pse/Mail/mbox                                             
1357
   [all of these are one long line]
procmail: Notified comsat: "pse(_at_)34968:/home/pse/Mail/mbox"
   [WHAT is this???]

Whenever procmail writes to a file, it checks the COMSAT variable.
To quote the procmailrc(5) manpage:

     COMSAT      Comsat(8)/biff(1) notification is on by default,
                 it can be turned off by setting this variable to
                 `no'.  Alternatively  the  biff-service  can  be
                 customised  by  setting it to either `service@',
                 `(_at_)hostname', or  `service(_at_)hostname'.   When  not
                 specified it defaults to biff(_at_)localhost(_dot_)

Check the manpages for comsat and/or biff for more info.


originally, among other status messages, I was getting:

procmail: Skipped "ARCHIVE"
procmail: Skipped ".listname"

when I was using mailbox names with periods in them (ARCHIVE.listname), 
but these went away when I changed the mailbox names to 
ARCHIVE-listname.  Why do I get grief using a period?

Got me.  I'd have to see the recipes that were causing the problem
to guess.


The idea was that if the mail was addressed to listname, we'd process 
it (mailing it to the recipients), and then save a copy to a crude 
archive file.

The end result I'm looking for is that any mail not handled by a 
previous rule (or which that rule specifies to continue on), will be 
forwarded and stored to a file.  I'd REALLY like it if the default rule 
at the end (which stores and forwards) would only store if it hadn't 
already been saved to an archive, but still always forward (I don't 
want to have to specify an address in the .forward file, as I don't 
want to see mail that is being archived or forwarded).

This is doable.  The LASTFOLDER variable is set to the folder name or
command name that last received the message.  If it's not set, then the
message hasn't been saved _anywhere_.  Thus, assuming I read things
correctly, the following should work:


:0 c
* LASTFOLDER ?? ^^^^
!PSE(_at_)ix(_dot_)netcom(_dot_)com

Note that there's no need to use a lockfile when forwarding, as multiple
sendmails can be run concurrently.


As long as I'm pestering everyone, is there a way to specify a file 
containing a list of email addresses to Sendmail?  I don't want to have 
to have the names IN the script (but at the moment, that is what 
works), and neither do I want to have the list mail contain everyones 
addresses.

As has been shown on this list several times:

:0 Aw
! $sendmailOPT `cat $file_containing_addresses`

This does have a limit on the total size of the address list, as
the kernel doesn't allow more than a certain number of args (or bytes
of args, one of the two).  If you hit that limit, you should really
consider moving to Smartmail, which works around it for you.


Actually, let me revise that.  Rather than going to all the pain that
you have, and more importantly, rather than continue to suffer that
pain as you self-maintain (with the help of the procmail list), why
don't you use Smartmail, and take advantage of the pain that has
already been expended in making it work?  Now if you're a masochist,
that's fine.  Just don't share your pain with the rest of us.


(That's a little harsh, but the point is: if you're struggling with
a tool, maybe you should use a easier tool.  I think Smartmail may
provide just such a simpler tool.  If you're struggling with a huge
procmailrc implemented mailinglist, then perhaps it is in order to
take a step back and re-evaluate how you want to do the list.  Yes,
changing over may be a pain, but will it save more pain down the line
when something else breaks later?  Forget the immeadiate cost; what
are the longterm costs going to look like?  This rant is an open
rant, and not necessarily directed at Sean.)


What am I doing wrong?

See above.


(BTW - this is a virtual domain configuration, so I don't have ROOT 
access to SENDMAIL as a delivery agent - everything sent to the domain 
goes into one POP mailbox).


Sucks to be you.  Bug your admin to add the 'envelope to' header to
your mailer.  (I'd suggest just adding it to just the program mailer for
philosophical reasons, but you should ignore me on this point
probably.)  Does someone out there have a reference on the full
directions for doing this?

Actually, I just noticed that your one formail command removes any
"X-Envelope-To:" headers.  If your sendmail is adding those locally
then you should be matching against them instead of with ^TO.  Doing
so will make your mailing lists work with Bcc's, etc.  It's also
much cleaner.


Finally, I think people have overreacted to the lockfile issue.
To make a generalization, everybody seems to be putting explicit
lockfiles on everything.  All those ARCHIVE-foo recipes can go
with implicit lockfiles, a la:

:0 c:
* ^TOTechFile
ARCHIVE-techfile



BTW: one of the reasons that you hadn't seen a reply yet is that you
asked difficult questions, which take a long time to answer.  I've now
spent almost an hour composing this reply, and to balance that I'll be
working an hour extra this evening.  Time is money: anyone telling you
otherwise is asking for a _non-returnable_ handout.

Philip Guenther

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