Andy Smith writes ("Re: master's mail backlog and upgrade time"):
> Instead of either side in this debate saying "Not my problem, you
> should do this..." how about reaching some compromise? It sounds
> like in the short term, Ian needs to discard some mail instead of
> rejecting, and in the long term master needs to be able to cope with
> this sort of thing. The absolute worst thing to do is to start
> generating bounces to these forged addresses however.
I would like to point out that the real original operational problem
here was _not_ that chiark was making master bounce junkmail.
The real problem was that the mail from from master to chiark
consisted so overwhelmingly of junk that chiark's teergrube kicked in.
The teergrube is _designed_ to soak up capacity from spamming sites.
It is of course a problem when applied to `friendly' mail flows[1] and
that's why I have now told chiark not to do that.
That the forwarded mail triggered the teergrube at all was due to the
fact that my debian.org mail forwarding arrangements predate the
Internet mail climate requiring the ability to selectively disable the
teergrube for forwarded mail.
So, I and some of my users' mail didn't have that feature turned on,
which is why master got bogged down. It is of course a bug in
master's mail system that one unfriendly host can sap all of its
capacity, but even without that bug there would still have been a
problem because _wanted_ mail via chiark wouldn't have got through.
This kind of thing (warring defensive systems) is going to happen
occasionally in the current mail environment. The important thing is
that when you see a problem with a supposedly-friendly system you
should talk to someone to get it fixed ! And, of course, that people
take a flexible attitude towards fixing things.
Otherwise we'll all be doomed.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
