Professional Software Engineering wrote on Fri, 28 May 2004 10:09:17 -0700:
IMO, that was pretty dumb.
No, if it fits your incoming mail structure, it's quite effective.
In the process however, you made the statement that nobody could do as good
a job with procmail as SA can. Not that SA might involve less personal
investment of time into managing the process, but that outright, SA was
better than anything anyone could implement in procmail.
No, I said:
it's got tons of specialized rules against
obfuscation, especially from rules emporium, which are guaranteed to work
better than any rules a single human can invent for procmail.
I've personally witnessed both sides. My personal experience says that
procmail wins out.
Good :-) As I said I'm not interested in a "what's better" debate, so I'm not
going to comment on your other arguments, this would just end in an endless
thread.
If reinventing the wheel is such a stupid idea,
what on earth were the people involved in SA thinking?
I don't know the origins of SA, but I think it was first coded to be only used
by procmail and similar as a spam arbiter. So, in this respect I guess the
reason to code it was that they felt there was no tool, including procmail,
which was able to do what they wanted. SA is as specialized for finding spam as
procmail is for processing and delivering mail. The reason for using SA is the
same as for using procmail or for using sendmail instead of coding your own MTA
or mail processor.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
IE-Center: http://ie5.de & http://msie.winware.org
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail