Steve Langasek writes ("Re: master's mail backlog and upgrade time"):
> Based on specifics (well... more-specific vaguenesses) mentioned by Ryan
> elsewhere, I don't believe this is the case. Chiark appears to be on the
> wrong continent to be attached to the user in question, and reducing one to
> two seems like a rather incredible off-by-one error to make in this case.
...
> Well, I certainly see a line in that file relating to chiark, but I have no
> exim-fu to understand the precise semantics -- and certainly no idea why
> it's there, sorry.
The configuration makes the mail domain disappear as far as master is
concerned.
The main effect is that master will never attempt to deliver mail to
the mail domain chiark.greenend.org.uk. That is, any recipient of the
form <something>@chiark.greenend.org.uk will be rejected or bounced
(as the case may be) with `Unrouteable mail domain'. As a
side-effect, any addresses forwarded to addresses @chiark (eg,
[EMAIL PROTECTED], which I do not publish anywhere and would rather get rid
of) are also undeliverable. Note, as a subtlety, that this does /not/
affect mail sent to any other domain for which chiark is the MX.
If a domain was set up to be treated this way for an unrelated reasons
without an announcement anywhere, surely that is even worse !
> On Tue, Nov 15, 2005 at 12:18:45PM +0000, Ian Jackson wrote:
> > * 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.
>
> No: there is nothing "proper" about rejecting mail from a host that you have
> configured to forward mail for you.
Nearly all of this mail flow is invalid in one way or another. The
most common case is that when chiark asks the MX for the envelope
sender about the envelope sender address, it turns out to be invalid
or unverifiable.
What is happening is that master provides a mail forwarding facility
with a lax input policy, but I forward my mail to chiark which does
stricter checks and has a stricter policy.
This has the effect of turning the rejected messages into bounced
bounces on master. This would be an unfriendly thing to do if the
sysadmins on master actually cared about reliable mail delivery and
took a policy of reviewing bounced bounces and dealing with their
causes (as I do on chiark). As it is, all it does is cause a bit of
work for computers as chiark is offered the mail, rejects it, and
master then turns it into a bounced bounce which will be discarded.
The problem with this using too much of master's capacity was due to
the teergrube (tarpit) feature as I described in my last mail. It is
of course a bad idea to treat incoming /forwarded/ junkmail flows as a
reason for teergrube because it just clogs up the (friendly)
forwarding host. That's why I have disabled this for my account (and
would have done so straight away if asked).
But, there is another important point: I don't really want a
debian.org address. It's technically necessary for me to have one for
(eg) cronmail from debian systems, and additionally I feel that there
is an (unwritten) rule that I should have one. But it is simply
untenable to suggest that I ought to accept all of this junkmail and
actually read it !
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
