Re: [exim] -qqff-like behaviour without the queuerunner?

Startseite
Nachricht löschen
Nachricht beantworten
Autor: John Burnham
Datum:  
To: Maarten van Baarsel
CC: exim-users
Betreff: Re: [exim] -qqff-like behaviour without the queuerunner?
-R suit your needs ?


-R<rsflags> <string>

The <rsflags> may be empty, in which case the white space before the string
is optional, unless the string is f, ff, r, rf, or rff, which are the
possible values for <rsflags>. White space is required if <rsflags> is not
empty.

This option is similar to -q with no time value, that is, it causes Exim to
perform a single queue run, except that, when scanning the messages on the
queue, Exim processes only those that have at least one undelivered
recipient address containing the given string, which is checked in a
case-independent way. If the <rsflags> start with r, <string> is
interpreted as a regular expression; otherwise it is a literal string.

If you want to do periodic queue runs for messages with specific
recipients, you can combine -R with -q and a time value. For example:

exim -q25m -R @special.domain.example

This example does a queue run for messages with recipients in the given
domain every 25 minutes. Any additional flags that are specified with -q
are applied to each queue run.

Once a message is selected for delivery by this mechanism, all its
addresses are processed. For the first selected message, Exim overrides any
retry information and forces a delivery attempt for each undelivered
address. This means that if delivery of any address in the first message is
successful, any existing retry information is deleted, and so delivery
attempts for that address in subsequently selected messages (which are
processed without forcing) will run. However, if delivery of any address
does not succeed, the retry information is updated, and in subsequently
selected messages, the failing address will be skipped.

If the <rsflags> contain f or ff, the delivery forcing applies to all
selected messages, not just the first; frozen messages are included when ff
is present.

The -R option makes it straightforward to initiate delivery of all messages
to a given domain after a host has been down for some time. When the SMTP
command ETRN is accepted by its ACL (see chapter 43
<http://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html>),
its default effect is to run Exim with the -R option, but it can be
configured to run an arbitrary command instead.


On 16 December 2015 at 14:25, Maarten van Baarsel <mrten+exim@???> wrote:

> Hi,
>
> Is there an exim incantation possible to deliver a lot of frozen mails to
> the
> same domain over 1 connection without using a separate queuerunner with
> -qqff?
>
>
>
> Yesterday I had a problem with MessageLabs refusing connections when
> delivering mails to a domain of a customer of ours. Once a connection had
> succeeded mails got through, but four connections later messagelabs refused
> connections again. My working hypothesis is that they implement some sort
> of
> fail2ban-like behaviour, and once triggered you stay on the 'bad boys'-list
> for a while.
>
> But, once you have a lot of mail queued up the normal queuerunners keep
> trying
> to deliver, the connections never succeed, and the queue keeps growing so
> you
> never got off the bad-boy list.
>
> As a temporary solution I froze all mails to the domain, waited an hour and
> ran a single queuerunner with -qqff but it didn't really deliver all mails
> over a single connection because, as far as i can see, before the 'second
> run'
> of the -qqff takes place all frozen mails are thawed which are then free
> for
> the normal queuerunners to deliver.
>
> I realize that I could have stopped the normal queuerunners but that
> would've
> stopped all other mail on the queue from being delivered...
>
> I tried exim -v -M [lots of messageids], but all mails got delivered over a
> separate connection.
>
>
> The documentation for queue_smtp_domains did not help me out, because it
> says
> "a delivery process is started whenever a message is received ... but
> instead
> the message waits on the queue for the next queue run" and my messages are
> already on the queue.
>
>
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_configuration.html
>
> Ideas?
>
> Maarten.
>
>
>
>
>
>
>
>
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/