On Wed, 2008-01-30 at 20:12 +0000, Arthur Dent wrote:
> On Wed, Jan 30, 2008 at 08:22:55PM +0100, Karsten Bräckelmann wrote:
> > :0 :
> > * [EMAIL PROTECTED]
> > spam/to-numerical
>
> Brilliant! It works! Thank you so much Guenther (and others who have replied
> off-list to help me with this).
>
> If I can have your assistance with just one other thing however. I'm afraid I
> really don't understand file-locking in Procmail (I have read the man and web
> pages) but I'm still baffled.
Do file-locking, when delivering to mbox files. Don't for Maildir.
When delivering, let procmail figure out the appropriate lock. In cases
where you don't deliver (filters, variable setting, pure nested logic,
whatever), either don't lock, or give a specific lock file IFF you want
it. For example, when filtering through SpamAssassin, you want a lock,
to prevent too many consecutive SA running.
> Now that I have it matching on the appropriate spam I want to rewrite the
> subject (in the same style as I have SA doing) and place it in the same spam
> folder as SA does so that I have it present for my nightly cron sa-learn job.
>
> This is what I have so far:
> :0:
Don't lock here. :)
> * [EMAIL PROTECTED]
It is useless to continue matching, if you don't care about the content.
The trailing '.*' does nothing, but keep procmail busy.
> {
> :0 fhw
> * ^Subject:\/.*
> | formail -i "Subject: [SPAM (XXX)] $MATCH"
> }
>
> :0:
> * ^Subject:.*\[SPAM \(XXX\)\].*
> IN-Spam
>
> I could not find a way to combine the matching, subject rewriting and moving
> into one step (is this possible?).
No. There may be exactly one action. Either a filter, or delivering.
However, unconditional receipts pretty much do exactly that.
> The above method works but give me the following error message in my Procmail
> log:
>
> procmail: Extraneous locallockfile ignored
> From [EMAIL PROTECTED] Wed Jan 30 19:47:28 2008
> Subject: [SPAM (XXX)] This is a test
> Folder: IN-Spam
procmail is right there. ;) No need for locking...
Below is a receipt, that should do what you want. Again: This is NOT
tested. The comments should be self-explanatory, as to when we want or
need locking. Also, it should add the spam tag to the subject even if
the original message does not have a Subject header.
Basically, we don't need to check for anything inside the loop. The one
condition exists only, to grab the existing Subject.
# catch bad numerical To: headers
# no locking here, since this block does not deliver
:0
* [EMAIL PROTECTED]
{
# grab the subject, if any
:0
* ^Subject: \/.*
{ SUBJECT = "${MATCH}" }
# add the subject spam tag in either case
:0 fhw
| formail -i "Subject: [SPAM (XXX)] ${SUBJECT}"
# deliver unconditionally (since we're here, we know we want to treat
# it as spam), DO LOCK here
:0 :
spam
}
> Help me fix this and I promise I'll be right back on-topic with all future
> posts (honest!).
>
> > When writing procmail receipts, it often helps a lot to remind oneself
> > of procmails supported REs by checking 'man procmailrc' or some docs on
> > the net. This one is a nice reference:
> > http://partmaps.org/era/procmail/quickref.html
> >
> > Hope the above helps. :)
>
> Oh it surely has!
>
> Many thanks
You're welcome. Hope this helps, too. ;)
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
