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