[Greylist-users] Central whitelist database

Eirik Oeverby ltning-greylist at anduin.net
Thu Jun 26 17:55:41 PDT 2003


Hi,

On Tue, 24 Jun 2003 22:35:34 -0700
Scott Nelson <scott at spamwolf.com> wrote:
> It's unclear to me that there is a "burden" upon users, or that
> if there is, that adding a fourth party to the email transaction
> is any better.  

As I stated in another reply to this thread, my biggest worry is the
initial delay that a lot of users are going to experience. Cutting down
on these delays (by having such a whitelist database accessible by all
MTAs) is, atleast to me, a very important measure to make greylisting
more user-friendly.

Ofcourse a combination of white- and blacklisting could be used, but I
think the blacklisting part can be covered by existing RBLs etc.

> That said, most of the same issues that apply to a blacklist
> would apply to a whitelist.  The ones I can think of off hand;

I'll give my views on some of them..

> . What are the policies for being added?

A submitter (becoming a subscriber/member/whatever with
'submit' access should require submitting verifiable contact
information) will submit the required information to identify a sending
MTA (or whatever we choose to whitelist), it will go into a holding
database, and after a sufficient number of other submitters submit the
same information, it will be accepted into the 'live' database -
together with references to the original submitter(s).

> . What are the policies for being removed?

A single complaint from any submitter (or perhaps from any
subscriber) should be considered enough to have a record removed. This
would make it possible for spammers to remove their adresses easily, but
in my experience most hosts sending spam are dial-up hosts, and it's
unlikely that the spammers will be able to 'predict' the IPs/hostnames
of the machines doing their dirty-work early enough to abuse this to any
significant degree.

> . Is there an appeals process?

The above should be enough of an appeals process IMHO. Ofcourse that
might be because I haven't thought of anything else yet ;)

> . Do I trust that those policies are being followed?

PGP/GPG signed distribution of sourcecode for the software running on
the servers, having only one software package capable of acting as
master server, slave server/submitter, and simple 'dumb' subscriber
node.

> . Is the list operator in danger of being sued?
>   (this is directly related to what the polices are.)

Now that's a question that needs to be adressed. I am not a lawyer or
anything even close, but I imagine that if the 'master' DB is in a
country like Norway or Germany it shouldn't be a problem. In the US it
might be a problem, and perhaps also other places. But a distributed
network of slaves with no 'masters' among them would probably not be
dangerous. Or maybe. Ask someone who might know.. :)

> . How comprehensive is the list?

I'm not sure I know what you mean here.

> . Would a DoS attack be possible?

Not sure. I guess it's always possible. But try to find the other
posting i made today about this, I am outlining in a bit more detail
what I think would be a good technical solution. I don't really see the
possibility of an effective DoS attack. Except perhaps if someone
grabbed the complete list of servers and tried to DoS all of them
simultaneously...

> The major advantage I see with whitelisting vs. blacklisting
> is that time to list, and time to report is far less critical.
> For greylisting, updates and comprehensiveness are even less
> important. If there was a "seed" list which I downloaded with the
> software, I probably wouldn't need (or want to bother with) any
> updates, ever.

Good idea. Or atleast an initial download of the list upon installation
or something.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.puremagic.com/pipermail/greylist-users/attachments/20030626/684f0576/attachment.bin


More information about the Greylist-users mailing list