On Sun, 16 Feb 2003, Professional Software Engineering wrote:
Search the archives for "multiaddr" and "domainlist" - about the middle of
last year, there was an extensive discussion of flagging messages which
addressed multiple like-named addresses or multiple addresses at one domain.
Thanks. I think I remember them; but had no clue about a keyword. And
Don has just provided some examples. Very interesting.
If you emit LOG items, they're useful to you when reviewing the log and
examinging why a message was filtered a certain way (or when
post-processing the log from a crontab event which produces a daily-run
report to be sent to you identifying new spams, etc). By setting a
variable (not even setting a header right away, just dumping info into a
procmail variable), subsequent recipes can check to see whether any
previous recipes may have matched. Without having to know what the
_conditions_ of that recipe were.
Ok, but if one is running all the messages through all the recipes; does
it make any difference? I can see where it might be helpful if one is
going to say "If you're over 5, you're spam, goodbye."
I see that you've already resolved that - yes, if you're not filtering
(through formail to add a header for instance, though other programs can be
used as filters), then the 'f', 'b' or 'h', 'w', 'i', and various other
flags are unnecessary. You're just setting a procmail variable - no copy
flag, or lockfile is necessary if that is all you're doing.
I trust you're using a SANDBOX to run your tests in?
Dammit, I *KNEW* you were going to gig me on that! :) Since all the
recipes had already been tested and all I was doing was changing a flag
and removing the delivery folder - I didn't. Hence the "panic" when
things went screwy on me! FWIW, I actually have two sandboxes set up - and
I use them often. Yeah, I know - excuses, excuses!
Do you set MAILDIR? LOGFILE? It might help to remember that those are
variables, and they retain their setting clear through until procmail
terminates.
Yes. I was concerned because I sometimes see things in the log that seem
to get out of sync - and I was looking at need for the w/W flags. Anyway,
this brings up another question. Someone in this discussion mentioned
unsetting a variable by the simple means of including it in the rc without
any parameters. I retrieve mail "manually" (ie, I invoke fetchmail when I
want to get mail) so procmail terminates after each mail session. Is it
necessary for me to unset my SPAMFLAG = "yes" variable at the beginning of
each session?
This has been an illuminating session. I'm still not entirely convinced
that a message can be "spammish;" but you've made a couple of comments
that have shaken my conviction. :)
Let me present the following poorly thought out analogy:
Intellectually, I understand what you're doing. My view, I suppose, is
terribly parochial; but *so far* all but a couple of my recipes have
returned absolute results. I suspect, based on these conversations, the
the *so far* is going to bite me sometime; but in the meantime, the bottom
line is contributing to my hardheadedness.
I'm considering those that don't work (for me) to be poorly written or
written using a bad approach.
- fleet -
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail