On Wed, 2002-07-10 at 19:24, Adrian 'Dagurashibanipal' von Bidder wrote: > [sorry NZ - of course I meant this to go here... how embarassing] > > On Tue, 2002-07-09 at 18:56, Not Zed wrote: > > [spam auto-complainer] > > > Where would it send it? > > I usually do > - reverse lookup of mailserver IP of the mailserver that sent the mail > to my mailserver. (Usually the first Received: header.) > - whois lookup of the same IP - sometimes the whois database contains > abuse contacts. > - submit the IP of open relays to ordb. Probably this would need some > special arrangement if suddenly all evo users would mass-submit hosts.
This doesn't sound particularly easy to automate. And open to abuse, and i bet any non-automated receiving agent wouldn't be fond of getting a burst of spam from evolution users, particularly if there are any bugs in the code. > I usually don't follow the Received: chain. Of course, with forwarded > mail and mailing lists it gets more complicated. Probably too > complicated to be done automatically. A 'look for List-ID header and > fail with informative message' function would probably be necessary to > protect list admins from over-eager spam-reporters. (Or, of course, a > very cool algorithm that follows the Received: chain and determines > which were forwarding hops from mailing lists/aliases and which was the > spammer's machine or the open relay. If you could come up with a foolproof mechanism, you could probably make money! Then the spammers would change their code and thats that. > > > > I think there's alreayd a feature request for this in the bug system > > (http://bugzilla.ximian.com/) anyway. > > 23110 > > Sorry - I hate the bugzilla ui, so I avoid it whenever I can. > > > Personally I can't see it getting done till we have some extensibility > > mechanism available. > > The mechanism described there sounds fine enough. Toolbar and keyb > shortcuts would neet to be configurable, then. (really user > configurable. Not 'change that file and be aware that it will be > overwritten/may break your system/may drink your beer' configurable) Extensibility mechanism means being able to extend evolution functionality without altering the core code. e.g. like emacs. If we had that, then better mechanisms than a pipe would be available, and a pipe would be trivial to implement. The problem is at the moment we have nothing. If we start adding a pseudo extensibility interface (such as 'add a button', 'run this program on click') it will just be duplicating code that will get thrown away when a real extensibility interface is written. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
