Re: anoncvs still slow

> > AFAICS, this is caused by the machine attempting to relay thousands
> > and thousands of spam emails (some quick checked showed a rate of
> > about 1 spam / 5 seconds enytering the queue - and I know I deleted
> > almost 20,000 from the queue)
>
> And how exactly would you like me to fix *that*? The reason
> those were in the queue is because svr4 is a legit MX record
> for the mailing lists ...
> the messages are being delivered into svr4's mail queue, and
> mail.postgresql.org subsequently refusing htem because they
> are for invalid addresses ...
>
> If I remove svr4 as an MX record, its just going to move to a
> different machine ...
>
> So, how exactly would you like me to "fix" that problem?

The complete fix is of course to apply the same ingress filtering on all
machines.

If that's not possible, do it as much as possible. As the email
addresses existing on svr1 is fairly static, it shouldn't be too hard to
teach svr4 (and other MXen if there are any) about them.

To make graylisting properly effective that also needs to be applied on
all entrypoints, otherwise svr4 will just solve the problems for the
spammers who have software that won't retry.

The quick fix is, as I wrote in one of my earlier mails, to configure
svr1 not to tell svr4 to *retry delivery*, but to just junk the mail
right away. It'll still cause joe-job style problems, but it won't load
up the queue for days.

> > For bittorrent, I propose we take it out. We've suggested
> it before, I
> > don't recall receiving any real requests to keep it, and
> IMHO it's way
> > much more pain than it's worth. Therefor, unless someone
> objects, I'll
> > pull the bittorrent links from the website in a couple of days, and
> > then we can just remove it from the server.
>
> That works for me ... let me know once its is down, and then
> I can easily do the upgrade ...

I'll give it a day or two more for people to complain, and then junk it.

//Magnus