[Greylist-users] stats from big sites?

[Ken Raeburn]

Brian Grossman <brian at SoftHome.net> writes:
> We accept several hundred thousand incoming messages per day.  I don't
> have statistics handy for how many we refuse.  Our greylist implementation
> is python+mysql+qmail.  Mysql 4.0.x on linux 2.4.x.  The greylist table
> is an innodb table, currently apx 8 million rows (a little over 8GB for
> data+indexes).

Thanks for the data, Brian.  That's big....  Any performance reasons
for python and qmail, or just your (site's) preference?

> The admin staff noticed a drop in spam after we turned it on.  The spam
> went back up a bit after osirusoft died.  I personally still get several
> hundred spam messages a day, most of which spamassassin catches.

Um, wow.  Several hundred a day?  That's scary.  Is this because
greylisting is only moderately effective in your case, or because you
would be getting ten thousand spam messages without it?

> Myisam doesn't handle the high volume of inserts and updates well, thus
> innodb.  The database load grew over the first month then tappered off.
> The database quickly outgrew it's disk space, then struggled under
> I/O load.

That's useful to know.  The site I've got in mind isn't quite as busy
as yours, but they'll want to plan for expansion, and the servers are
already badly overloaded at times (though I don't know if it's CPU or
I/O that's the problem).  Myisam is working fine for my 400+ records
and 15-20 messages an hour, but that tells me nothing about a "real"
deployment.  Any performance problems since you switched to innodb?

I had figured on recommending a separate database stored on each
server.  But given the size and performance load you're describing, I
wonder if a separate shared database server might not be a better
idea.

> Most of our users have accepted greylist without complaint, probably not
> even noticing it.  Of those who do notice and complain about the delay,
> most are happy to put up with the delay after we point to a FAQ about it.
> Others need to receive email quickly and either upgrade to a pay account so
> they can control it or presumably leave.

Sounds like it's been well received, especially with the ability to
control it.  I expect we'd probably have to have that option from the
start, as well.

> If you're going to do a trial run, I suggest you put some volunteers on it
> and run the others in learning mode for a month and a half.  That should
> give you an idea of resource requirements and give you an idea of user
> experience.

Just the kind of initial trial I was hoping for, yes.  Though with the
amount of time the people running the mail server have to even listen
to me (i.e., none yet, and probably not for a while), it may instead
have to be a small test with a new server, different advertised domain
name in the email addresses, etc.

> One other suggestion for user experience: let end users adjust the color of
> the entry (black, white, grey, etc) and add and delete entries.  It can
> then also be used as a general purpose black/white list.

Yep, once the administration service is there, there's no reason not
to allow this level of control.  Some of the access control issues
relating to mailing lists will be tricky because of the way the site
handles list administration, but I've got some ideas....

(Though, come to think of it, letting one user add three million
whitelist entries for himself may not be a great idea.  Well, we can
see about burning that bridge when we come to it.)

> Our python code for greylist is available by request.

Great.  I may ask you for it... it's a sendmail site, but using python
would probably be a plus, if only because one of the important people
recently became a python enthusiast. :-) Right now, I think I may be
too far from being able to get anything deployed for it to help me.

But it might be good to get another implementation onto Evan's web
site.

Ken