procmail
[Top] [All Lists]

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

1996-05-01 09:50:04
PSE(_at_)ix(_dot_)netcom(_dot_)com (Professional Software Engineering) writes:
Philip Guenther wrote:
As for it affecting your regular mail, put the following right before
the mailing list rules:

:0 c:
$DEFAULT

DELIVERED = yes

How can I set the DELIVERED flag any time I place the incoming message into a 
folder?  The procmail man page seems to indicate that this is what controls 
whether the message bounces or just falls into the bit bucket, but I've never 
experienced bouncing without it.

A message bounces only if no delivering recipe was ever performed, and
the DELIVERED variable was _never_ set (you can't 'unset' it).  Since
procmail acts if there was an implicit
        :0:
        $DEFAULT
            :0e:
            $ORGMAIL
at the end of the procmailrc(s), mail should only bounce if procmail
can write to neither $DEFAULT nor $ORGMAIL.  Setting DELIVERED is not
necessary for normal processing.  Indeed, DELIVERED doesn't stop the
implicit rules shown above.  The usage that you quoted is for testing
purposes only: you'll end up with duplicate mail for most of your
messages.  Indeed, if you didn't get duplicates for 'normal' mail, then
something is wrong with the rules that follow.

So the answer to your question, is that you _don't_ want to set the
DELIVERED variable.  The mail would still end up being forwarded.
Instead you should match against LASTFOLDER to see whether it's been
saved.


The other thing though -- ultimatley, at the END of the script, I want it to 
save a copy to an archive file, as well as forward -- so long as the message 
hasn't been saved to another folder.  You gave me the script info for that:

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

except that I want to both store AND forward.  I've tried, without success to 
place them in braces:

:0 c
* LASTFOLDER ?? ^^^^
{
! PSE(_at_)ix(_dot_)netcom(_dot_)com
ARCHIVE-inbox
}

as well as another method:

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

:0 a: $TEMP/Default$LOCKEXT
$DEFAULT


The contents of a nested block are simply recipes.  Just as

! PSE(_at_)ix(_dot_)netcom(_dot_)com

will be ignored outside of a recipe, it'll be ignored in a block outside
of a nested recipe.  What you wanted to say was either:

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

or

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

:0 Ac:
$DEFAULT


Note that you have to put the 'c' flag on both in the latter option.


(I've tried this both with "A" and "a", though I think under the 
circumstances, "a" is more appropriate).  In both methods, I ALWAYS end up 
with a copy being saved to the folder.

You're forgetting the implicit terminal rules.  If you fall off the
bottom, a copy will go into $DEFAULT.  If you don't want that to
happen, make sure a delivering recipe (that is, one without the 'c' or
'f' flags) is in there.

Part of the problem (I think) is that it's not clear when you're done
processing a message.  If a message is archived into ARCHIVE-foo, are
you done with it? If not, when _are_ you done with it?  After it's been
forwarded to the addresses in file addresses-foo?  Any message which
should not be forwarded to your real address and/or dropped in $DEFAULT
should never see the end of the sub-procmailrc (boxes.rc?), but should
have hit a delivering recipe in there.



As for 'A' vs 'a', I think 'A' would be more appropriate.  Anyway, I
don't think the flag differ if the preceding recipe was a program or
forward without the 'w' or 'W' flags.


(the reason I explicitly declare the lockfile is because the names that show 
up in the log often look hokey -- I figure there isn't much lost to 
explicitly declaring something)

"Hokey"?  How so?  They should look like the mailbox name with $LOCKEXT
appended.


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

Apparently, they're not consistently expanded in the LOGFILE, which, when I'm 
looking for reasons things are failing, looks mighty suspicious.  I dunno, 
all this stuff is black magic I think.

They don't expand inside of single quotes.  Could that be it?  I'd
have to see an example to diagnosis any more on this point.


...
The admin of the (small) ISP I use is running it on FreeBSD (for whatever 
reasons), and indicates that he is unaware of any FreeBSD port of smartmail.  
I'm going to do some digging around, but in the meantime, the tool is 
unavailable to me.  I was unaware of smartmail -- I shall endeavor to learn 
more about it in case I have to implement further mail list functionality.

Smartmail shouldn't need porting.  It's just a collection of procmailrcs
and stuff, combined with the program 'multigram' whose source comes with
procmail.  If procmail works, then smartmail will.  You can get it from
the same places you get procmail.


...
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.

The sendmail locally doesn't add them.  I've asked the sysadm to check into 
adding them though, since of course, messages sent to MULTIPLE addresses at 
the same domain have a slight parsing quandary.

That's why I'd suggest adding it to only the program mailer: they have
to be done one recipient at a time anyway.  Then you just make sure you
have an explicit .forward containing the "|/usr/local/bin/procmail..."
or whatever.


Philip Guenther

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