Re: [Evolution] FRQ: spam-complaint

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
( anyway.


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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]