Ryan Murray writes ("master's mail backlog and upgrade time"):
> Also, I've investigated the mail backlog on master and found the main
> problem. The mail queue is currently full of email that will never be
> able to be delivered, all for one particular user. This mail is being
> removed from the queue, and the setup changed to not deliver to the
> problem address. Once this is finished (a few days), mail latency for
> mail moving through master should be greatly improved.
I have now discovered that the `one user' referred to is at least two
of the users of my colo system, chiark.greenend.org.uk.
I am upset because I was not told of the problem and given any chance
to help fix it, and because the announcement was sufficiently
inaccurate that even though I read it and even investigated in my
logs, I concluded - erroneously but without error on my part - that
chiark wasn't involved.
I would like to point out the following facts:
Regarding the announcement and its lack of accuracy, and the lack of
communication with the persons responsible:
* At least two people with @debian.org addresses have mail forwarded
to chiark: myself <[EMAIL PROTECTED]>
and Alan Bain <[EMAIL PROTECTED]>.
* Several other Debian developers have chiark addresses, or have mail
domains hosted by chiark.
* When I read the announcement I read it carefully and also searched
my logs, to check whether my systems were involved. On discovering
in my logs quite a few rejections of mail to _two_ users, I
concluded that since the announcement talked about `one particular
user' (not `one particular host'), I was not affected.
* I now discover by reading master's exim4.conf that all mail
to the _mail domain_ chiark.greenend.org.uk has been arranged to
bounce on master. This is contrary to what is stated in the
announcement, which says that the setup was changed `to not deliver
to the problem _address_' (emph. mine).
* No serious attempt has been made to contact me about this problem,
either in my role as sysadmin for the affected host, or as one of
the affected users. [EMAIL PROTECTED] would have
been happy to help for example - and yes, a message to postmaster
would have got through.
* No clear thought was given by the system administrators as to the
possible collateral damage of never attempting to deliver mail to a
particular mail host. One example of such collateral damage is
that several members of the Technical Committee receive mails for
debian-ctte-private _via_ an alias on chiark; we set up this
arrangement after the Debian systems proved unable to maintain a
simple mail alias without occasionally having people fall off it !
Regarding the problem and how to solve it:
* The mail backlog that `will never be able to be delivered' was
(as far as I can tell) all spam that chiark has been properly
rejecting. Usually, the messages have invalid envelope senders.
* It is unfortunate that (a) master has such a lax spam policy and
that (b) Debian developers cannot choose to make their @debian.org
address unuseable other than by the Debian system administrators.
This problem (lax policy at more-upstream mail host) always results
in a lot of downstream rejections.
* I guess that part of the problem was that the volume of mail
rejections (92 rejected SMTP commands in the week ending 2005-10-23
11:42 UTC) engaged chiark's teergrube feature. This deliberately
delays the SMTP responses to hosts which are generating lots of
errors, because those hosts are usually spammers or zombies.
* chiark has had the ability, since September 2003, to mark certain
mail flows as `OK to have lots of errors' (this feature postdates
the mail setups for my and Alan Bain's mail forwarding, which is
why it wasn't already configured for those). That would prevent
the teergrube, although it would not prevent the spam rejection of
course. I have made this configuration change for my personal
account and I will be forwarding a copy of this mail to Alan.
* master should immediately be configured as follows:
1. The special case for chiark in exim4.conf should be removed
2. If this will make the situation untenable, mail for
[EMAIL PROTECTED] should be rejected by master at SMTP-time, probably
by using rootly powers to edit ~afrb2/.forward.
3. Alan should be notified of 2. and asked to sort it out.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
