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

Re: Bug#75853: TONER CARTRIDGES



>>>>> "Mako" == Mako Hill <mako@debian.org> writes:

    Mako> On Fri, Sep 20, 2002 at 02:58:04PM -0400, Joey Hess wrote:
    >> Michael Stone wrote: > One possible approach would be to use a
    >> confirmation process for > followups that don't contain either
    >> quoted text or subject line from the > parent. Implmentation is
    >> left as an excercise for the user. :)
    >> 
    >> Yep, or run the bug mails through spamassassin and dump those
    >> that look like spam to a moderator list.

    Mako> This seems like the obvious answer to me. I imagine the
    Mako> problem is finding the person who want to sort through the
    Mako> (huge amount of) spam.

With a little groundwork (ie, creating the infrastructure) this wouldn't
be that difficult.

Of al that spam/possible spam, very few (any!?) would be real mails. Finding
those would only take a few minutes (?). Then a mail to the 'controller'
is all it takes ('release #xxx' - where 'xxx' would be a message number).

This 'controller' then let's the mail through, all others are deleted (after
a period).


If SpamAssasin could be setup, it wouldn't take much to modify it to implement
this:

        - A reply from specified address(es), signed with specified PGP/GPG key(s)
          with the specified command(s) will release the specified mail(s).
        - All mails not released in that batch is deleted.

'in that batch' would indicate:

        - Once every 24 hours a mail is sent to specified address(es) with
          all mails caught as suspicious is included as attachments (OR, even
          better - on a URL which is only accessible by the 'spam police @ Debian').
        - Above each suspicious mail is a number (created by the controller).
          This number is used as 'release #xxx' above.

Now, the controller:

        - Either a modified SpamAssassin, or a homemade one.
        - One that finds all suspicious mails and sends it to a controller
          address.
        - This address is a list of people that is interessted in helping out.
        - One address is chosen in random, so that not ONE person does all
          the work.
        - The verification of the release commands should be PGP/GPG signed
          by the person sending the commands. That person's PGP/GPG key is
          fetched from a keyring.
          - We might be able to use part of the voting enging for this!
          - Preferably ANY Debian GNU/Linux developer should be able to
            do this.


This is naturaly just a first step in this design, I wrote it from the top
of my head. No real thinking was done, so...
-- 
BATF toluene Peking supercomputer Iran Ft. Meade killed explosion
NORAD Cuba Saddam Hussein KGB Soviet radar NSA
[See http://www.aclu.org/echelonwatch/index.html for more about this]



Reply to: