Re: Actually... Re: [Cooker] Wishlist: spam filtering
On Wed, Aug 21, 2002 at 10:13:04PM -0400, allen wrote: > Conceptually I'd need just one rule iptables -A input -j QUEUE > Plus the rpm -ivh of a hogwash-iptables.rpm or rather "by" > such an rpm. Yes but a real person needs to be there to insert such a rule in the right place. If you put it in the wrong place in the chain it could have drastic results. There is no program that automatically installs the hogwash rule into iptables for you... The context of the rule is very important especially in procmail and iptables. In order to decern the context you'd need an AI. Which you aren't going to get from an rpm package produced by Mandrake. > If there's a market, your bank account would argue with you. > > But then, I'm not even suggesting that there might be thousands or > even millions of people and businesses of all sizes with a > spam problem... And enterprises have system admins who can take the 20 minutes to install and configure spamassassin. They don't leave such things to end users to setup. And that's ultimately what the request is trying to take care of. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Re: Actually... Re: [Cooker] Wishlist: spam filtering
On Wednesday 21 August 2002 10:18 pm, Ben Reser wrote: > On Wed, Aug 21, 2002 at 07:15:37PM -0400, allen wrote: > > http://www.prismnet.com/~aef/index2.html > > http://hogwash.sourceforge.net > > I'm not actually trying to promote these things for this purpose at this > > time, I am just saying that this issue is really not "impossible". > First of all your examples are all things that manipulate iptables rules > and require a lot of setup to make work on the users perspective. > Comparing that to something that is going to (without an user > intervention) modify procmail rules and not cause an interaction (and > procmail is rife with interactiosn) is silly. Yes and no. You are actually assuming quite a lot here. Seriously, humbly. ( I would take this part off-line and post a summary, can be a while off topic ) > But that's beside the point. It's a waste of Mandrake's time because > the *correct* way of implementing this is providing hooks in the client > and the server. Whatever. I'm not suggesting anything other than the fact that it is not impossible ;) > This will probably happen sooner or later and Mandrake > would spend a lot of time and energy implementing something that: a) > would break for a lot of people and b) will become obsolete when the > clients do implement the hooks. I understand and yes, no reason not to have the right hooks in the right places. However there is also no reason to have to have what you might consider "enterprise" or "edge-level" rules administered in each and every application throughout your network... Thus there are things that can make a pervasive difference from a single vantage even just a single machine... Things like hogwash. > So it's just not worth the time. IPTables is installed on my beta 3. Conceptually I'd need just one rule iptables -A input -j QUEUE Plus the rpm -ivh of a hogwash-iptables.rpm or rather "by" such an rpm. Like... squid, snort, etc., Time is money. If there's a market, your bank account would argue with you. But then, I'm not even suggesting that there might be thousands or even millions of people and businesses of all sizes with a spam problem... ;) -AEF
Re: Actually... Re: [Cooker] Wishlist: spam filtering
On Wed, Aug 21, 2002 at 07:15:37PM -0400, allen wrote: > Uh, it's not really "impossible". ( ...borrows fireproof pants ) > > http://www.prismnet.com/~aef/index2.html > ( I mention this one only because of applicability to a stand-alone system > based on Mandrake with Netfilter and libipq. ) > > http://hogwash.sourceforge.net > > I'm not actually trying to promote these things for this purpose at this time, > I am just saying that this issue is really not "impossible". > > Not kidding. Not enough time and developer bandwidth or it would be more than > possible already for this purpose. First of all your examples are all things that manipulate iptables rules and require a lot of setup to make work on the users perspective. Comparing that to something that is going to (without an user intervention) modify procmail rules and not cause an interaction (and procmail is rife with interactiosn) is silly. But that's beside the point. It's a waste of Mandrake's time because the *correct* way of implementing this is providing hooks in the client and the server. This will probably happen sooner or later and Mandrake would spend a lot of time and energy implementing something that: a) would break for a lot of people and b) will become obsolete when the clients do implement the hooks. So it's just not worth the time. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Actually... Re: [Cooker] Wishlist: spam filtering
On Wednesday 21 August 2002 07:56 pm, Ben Reser wrote: > An excellent point. As it stands now the only way to run spamassasin is > through procmail (well okay Mail::Audit too but nobody really uses that > [/me puts on flame retardent pants here]). But if you're using Kmail > and checking directly via POP or IMAP you can't use procmail so it won't > work. Which comes back to my statement that it's impossible to do > because there are too many different client/server configuration > possibilities. Uh, it's not really "impossible". ( ...borrows fireproof pants ) http://www.prismnet.com/~aef/index2.html ( I mention this one only because of applicability to a stand-alone system based on Mandrake with Netfilter and libipq. ) http://hogwash.sourceforge.net I'm not actually trying to promote these things for this purpose at this time, I am just saying that this issue is really not "impossible". Not kidding. Not enough time and developer bandwidth or it would be more than possible already for this purpose. FYI -AEF
