The method we are playing with is a huge data base of specific
subject lines, 100,000 or more created by our users themselves as they
cast spam into a spamtrap. Users who wish to subscribe to the spam filter
will do so on a web page, but anyone can send spam to the spamtrap.
The procmail action line needs to look up the user and the subject
line in the two data bases, and then take action for that e-mail depending
on 1.) whether it found the subject line, and 2.) what the users
preferences are.
A straight forward procmail recipe with 5000 recipe lines in it
stopped the mail server cold.
All we want is a simple recipe that will direct all e-mail
to the program of our choice, and then deliver the mail according
to something set in the spam program. The spam program
is being designed around many different needs and may itself
become quite complex depending upon what users want.
What I don't want to have to do is actually *DELIVER* mail.
If procmail can do all this without a secondary piped program
I am all ears.
------------------------------------------------------------------------
Homer Wilson Smith Clean Air, Clear Water, Art Matrix - Lightlink
(607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY
homer(_at_)lightlink(_dot_)com Is that too much to ask?
http://www.lightlink.com
On Tue, 6 Mar 2001, Colin J. Raven wrote:
Why would you want *another* program (other than procmail) to do what
procmail is designed to do natively?
The criterial you refer to below can be established via recipes, and the
range of criteria available to you are almost limitless. The only limit is
your imagination.
The complexity of doing up a shell script to delineate what/where/how of
mail routing....*followed by* handing off the mail back to procmail sounds
to me like a complicated way to do an essntially simple task, plus you
incur additional CPU overhead needlessly. Add to that the issue of future
maintainability.
Take a look at John Hardin's spam filter kit at:
http://www.impsec.org/email-tools/procmail-kit/procmail-kit.html
and, for security *plus* spam filtering, consider John's "Enhancing email
security with Procmail, found at:
http://www.impsec.org/email-tools/procmail-security.html
If this is too industrial-strength, you can certainly "roll your own" with
individual recipes tailored to your precise local needs.
IMHO (and I defer to the Gods, Gurus, Wizards and Deities on this list
from whom I have learned all I know about procmail) the questions you pose
below are too wide to be answered easily. You need to narrow the focus of
the question, and also define why you want to use something external too.
(I'd be interested to know, for one).
Give this some thought and follow up with narrower questions. I'm certain
that we can help you come up with something simple, inexpensive
(overhead-wise) and probably elegant to boot, which will serve your needs.
Regards,
-Colin
--
Colin J. Raven
On Mon, 5 Mar 2001, Homer Wilson Smith wrote:
I wish to build a simple spam filter consisting of a single sh, perl
or C program that receives all mail coming into our system for all users,
and decides on its own internal criteria,
1.) Deliver the mail to /var/spool/mail/$USER
2.) Deliver the mail to /var/spool/spam/$USER
3.) Deliver the mail to /dev/nul
Would someone please quickly explain how this script is called in
/etc/procmailrc? I would like to avoid having the shell script do the
delivery of the mail itself, but wish to pass the mail back to procmail
for final delivery.
This probably won't work :)
0:
| spamprogram
Pointers to RTFM are welcome.
Thanks Homer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail