On Sun, Mar 19, 2006 at 10:16:39PM -0700, s. keeling wrote: > Incoming from Dave Sherohman: > > That's beside the point, IMO. All the documentation and syntax > > checkers in the world aren't going to change the fact that procmail's > > > > :0: > > * ^From: AntiSpam UOL <[EMAIL PROTECTED]> > > /dev/null > > > > (stolen from one of Gene Heskett's recent posts) is more cryptic and > > Your opinion. You like tools that speak English. I like tools that > work; I don't care what language they speak.
I like tools that work and prefer that they speak something similar to English and/or another, standardized language (preferably one that I know, such as C). Which brings us right back to the question I initially asked when I started this subthread: Is there anything that procmail can do which exim filters cannot? Does procmail have any real advantage over exim filters other than being a widely-used legacy application, within the context of talking about a system (i.e., Debian) in which exim is the default MTA? So far as I am aware, procmail's only advantage is that it can be used with any MTA. If this is correct (and it quite certainly may not be), then I question whether people who are being given their first introduction to config-file-based mail filtering, and are doing so on a system which uses exim as its MTA, should be immediately directed to a solution which requires them to either learn a unique, special-purpose language for that one purpose or else blindly cut-and-paste text from recipes provided by other people with little or not understanding of what it means. I have nothing against complexity, but I have a dim view of pointless complexity. Does the additional complexity of learning procmail bring along an additional benefit or is it just pointless complexity? -- The freedoms that we enjoy presently are the most important victories of the White Hats over the past several millennia, and it is vitally important that we don't give them up now, only because we are frightened. - Eolake Stobblehouse (http://stobblehouse.com/text/battle.html) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
