Re: MX/ISP BLOCK

Mark David Dumlao <[email protected]> Sat, 9 Feb 2019 12:24:01 +0800
Newsgroups gmane.mail.qmail.general
Message-ID <CAG2nJkN18j3F4z6R5cQ+NM2Brx+6XVPXwyz1Z1q0U7F7aykRxQ@mail.gmail.com>
On Sat, Feb 9, 2019 at 6:13 AM Charles Cazabon
<[email protected]> wrote:
>
> Rejaine Silveira Monteiro <[email protected]> wrote:
> > This ISP is off the air and hundreds of messages from multiple clients
> > are standing in line. The problem is that this is generating a huge
> > delay in delivering to other customers of other ISPs.
>
> Others have made suggestions on how to cause these messages to be delivered to
> another machine or bounced, however...
>
> qmail is pretty good about handling cases like this.  Normally, each message
> will be tried on the usual delivery schedule, which uses a scaling
> (geometric?) backoff algorithm, so messages that have been sitting in the
> queue waiting for this ISP to come back shouldn't actually interfere with
> delivery of newer messages to responsive hosts.
>
> Are you certain you actually have a problem, or are you just worrying when you
> needn't?

This can actually become a very serious problem. Qmail has concurrency
limits, which you may need to adjust as appropriate. Basically, if a
large percentage of your queue is undeliverable mail - specifically
the kind that qmail has to wait for a timeout - a lot of mail time is
wasted by qmail waiting for those connections to time out, whereas
valid mails are waiting in an ever-growing queue. It gets compounded
as both the mailserver and user retry sending mails. I've once gotten
to a situation where 90+% of the queue was dead mail due to some
"reply all snowball of hell" gone wrong. My stopgap solution at the
time was to hunt down mails in the queue and take them out, but also
to increase the default concurrency to a stupid amount to mitigate
this in the future.