Re: [Evolution] FRQ: spam-complaint

[Not Zed <notzed ximian com>]

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.