On Wed, Jun 21, 2006 at 03:12:40PM -0700, Don Russell wrote:
Dallman Ross wrote:
I've test this. It seems to work.
LOCKFILE = msgid.russell$LOCKEXT
:0
* ^Message-id:(_dot_)*(_at_)drussell[(_dot_)]dnsalias[(_dot_)]com>
* ? formail -D 8191 msgid.russell
{ }
LOCKFILE
:0 fw h
* ^In-Reply-To:(_dot_)*(_at_)drussell[(_dot_)]dnsalias[(_dot_)]com>
* ^X-Beenthere:.*procmail
* ? formail -IMessage-ID -RIn-Reply-To Message-ID -D 8192 msgid.russell
| formail -A "X-Special-Flag: Followup to me!"
I think the LOCKFILE name should be something else. Maybe
someone can refresh my thinking on that topic.
That is interesting.... WOW! I just learned another great
thing.... the LOCKFILE variable... according to my "procmail
companion" book, that needs to specify a path. The book is a
We need a path if it's not in the current dir, which we can
set with the MAILDIR directive.
little vague.... it goes on to say if the specified file exists,
then procmail waits until the file does not exist. I take that
to mean that setting this varible will create the file if it
does not exist, and then continue. un-setting the variable then
deletes the file... I'm guessing that the lock names are stacked
LIFO in case multiple locks are used.
No. Bart answered this already, but ... no. There is a global
lockfile, and it's either on or off. It's always off be default
unless we explicitly turn it on by setting it to a name (file).
If you rename it, then the original one vanishes instantly.
If you unset it, then it also vanishes.
My question above was specifically as to whether the name for
the lockfile needs to be something other than the file I wish
to write to (plus $LOCKEXT). I think that is so. Otherwise,
we'll wait for the LOCKFILE to go away and we won't write
to the file. I wouldn't mind someone confirming my thinking
here, though, as there seemes to be some logical detail I'm not clear
on at the moment or have forgotten.
However, in my testing, even if I name the global the same as
the file + $LOCKEXT, formail has no trouble writing to the file.
So I suppose the global lock simply stops other procmail processes,
but not formail.
And just about TWO days ago I was wondering how I could possibly ensure
serialized execution of two recipes.... the LOCKFILE variable...
whu-who!! :-)
(The spelling would be: "woo-hoo!!") :-)
The global lockfile can work, but it's often a bad choice for this,
because it stops all parallel procmail processes until it's finished.
You can use the "w" flag on a recipe to cause it to wait, also.
(It waits so it can evaluate the exit code.)
Also, one could use a similar trick to send mail to the
spam pile if it has "RE:" or "FWD:" in the Subject, is
not from a trusted person, and is not a follow-up to something
whose Subject is in a cache. That is, I'll let whitelisted
folks send me RE: or FWD: stuff that I hadn't seen originals
to, but for unvetted people, they've no business sending that
to me, and it's a good spam indicator.
Handling of Re: and FWD: in the subject is tricky depending
one your own situation.... if you deal with people in other
languages/countiries... "Re:" may be in French for example.
I know all that. I also have German correspondents, for example.
But I'm not talking about RFCs. I'm talking about smart spam-
fighting. Spammers send me spam with "RE:" and "FWD:" by the
hundreds. If I've never seen the base Subject: before, I have
no reason to read something "RE:" that subject, right? Otoh,
sometimes people I've whitelisted send me cc's of a discussion
_in medias res_. I'll allow that -- that's one reason they're
whitelisted, after all.
There are no RFCs covering the use of Re: etc in the subject line.
It's also fine per the RFC's for a Subject to say "RE:Something"
(since a subject can say anything 7-bit). But since mail programs
don't format without a space, we can assume it's a spammer who
sent that.
Regarding my suggested code, we can probably refine it some.
We can set the global (David Tamkin would call this a "regional")
lockfile only if conditions are met. We can run the second recipe
only if the first failed to run, for complex reasons I'll explain
below.
#########################################################################
# let's only run this set only if it's a list. The condition
# here is simply one example of something that can signify a list
:0
* ^X-Beenthere:
{
IFMSGID = @drussell[.]dnsalias[.]com> # change as desired
:0
* $ ^Message-id:.*$IFMSGID
{
# much better to spawn one extra pair of braces
# than to invoke global on all mail
LOCKFILE = global$LOCKEXT
:0
* ? formail -D 8192 msgid.mine
{ }
LOCKFILE
}
# if it was our Message-Id, we sent the message,[1] so
# we don't need to bother looking for In-Reply-To: in
# order to set special handling; hence the 'E' flag
#
# [1] Or a spammer sent it, but we don't need this test then, either
:0 E fw h
* $ ^In-Reply-To:.*$IFMSGID
* ? formail -IMessage-ID -RIn-Reply-To Message-ID -D 8192 msgid.mine
| formail -A "X-Special-Flag: Followup to me!"
}
#########################################################################
I've tested this, and it works. However, note that if an In-Reply-To
header is found with your domain in it ($IFMSGID, to be specific), but
that string wasn't found in the "msgid.mine" cache, it will now be added
to the msgid.mine file. The message won't get the special-treatment flag
added (that's as it should be), but the cache is now expanded with the
false-poz. That shouldn't matter, though. And it would only happen
if you (or someone pretending to be from your domain) followed up to
yourself to the list, but somehow the original Message-Id wasn't in
the cache. It's an interesting side-point, in other words, but should
not affect the workability of this algorithm.
Dallman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail