At 22:59 2003-02-15 -0500, fleet(_at_)teachout(_dot_)org wrote:
> there are some good recipes which look for an abundance of official-type
> addresses (multiple-domain spams).
In the last three or four days I've received spam for both "webmaster" and
"info" - not worth messing with the list.
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.
> >Ok. Currently I use LOG to record the "rule" that identifies a message as
> >spam. Looks something like:
>
> But LOG emits it to the log - the rest of the recipe doesn't have realtime
> access to that information.
I don't understand why it would need to.
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.
This just provided a few panic-filled moments! I had it in my head that
a recipe wouldn't continue without the c flag. Of course the fhw flags
didn't work either - no pipe! I think I'm ok now.
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?
> The VARIABLE. It remains set as you progress through the procmailrc.
Somehow I was afraid that the VARIABLE wouldn't necessarily accompany the
message through the filters. Sometimes I think funny, I guess.
Do you set MAILDIR? LOGFILE? It might help to remember that those are
variables, and they retain their setting clear through until procmail
terminates.
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:
spammish is to your email box as the following are to your stereo business:
people loitering around your shipping dock
people loitering around your business at night
people loitering around when your business is closed
people wearing sunglasses and trenchcoats
unrecognized vans parked after hours near your business
(I could go on and on)
Any one or two of the above might be reason to pay note something, but as
the number of "iffy" conditions increases, so does the likelyhood that
something is amiss.
I think you'd consider calling the cops if there was an unrecognized van
parked outside your shipping dock after hours with a couple of guys in
trenchcoats sitting inside, and chances are, you'd be right for calling the
police, even if they couldn't bust them for anything at the time.
Now, apply the same logic to email - any one condition may not be
sufficient to identify a message as spam, but several (which independantly
may be based on complex expressions of their own, and therfore wouldn't be
appropriate to put into a single "mega" recipe) spammy characteristics will
help identify a message as warranting rejection.
Another Vermont yankee characteristic I guess - hardheadedness!
That beats emptyheadedness every time.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail