prioritization in qmgr scheduler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

prioritization in qmgr scheduler

Deniss
Hello,

I looking for a way to speed up delivery for specified sender's domain
when incoming queue is overloaded.

I have idea how to achieve this by using another postfix instance and
looping messages through it.

May be it is possible to configure qmgr scheduler to prioritize messages
by senders domain or run another qmgr for specific domain to pass
messages in first place on same postfix instance ?

Deniss
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Wietse Venema
Deniss:
> Hello,
>
> I looking for a way to speed up delivery for specified sender's domain
> when incoming queue is overloaded.

When the road to the airport is clogged, everyone has to wait.

BTW, Postfix has the smtp_fallback_relay feature for moving
deadbeat destinations to a different queue. It has the same
effect as expediting all the other mail.

> I have idea how to achieve this by using another postfix instance and
> looping messages through it.

Yes, using a different queue is like building a different road.
Then, one road will hopefully not be congested.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Deniss
On 2017.08.23. 15:28, Wietse Venema wrote:
> Deniss:
>> Hello,
>>
>> I looking for a way to speed up delivery for specified sender's domain
>> when incoming queue is overloaded.
>
> When the road to the airport is clogged, everyone has to wait.

> Yes, using a different queue is like building a different road.
> Then, one road will hopefully not be congested.
>


well, I want fast lane for certain domain indeed.

I looking for a way to implement this with no dedicated postfix instance.
I feel there is a way with restriction classes + dedicated qmgr or smtp
service(s)

let me explain my setup:
I have postfix as frontend to absorb incoming messages as fast as possible.
Then I have slow smtp backend.
Postfix limits delivery to backend with
smtp_destination_concurrency_limit = 2
This works pretty fine allowing to not oveload backend on peaks -
messages become queued at frontend and delivered with some delay to backend.

But now I want to deliver certain domain with no delay.

Is it possible to catch the sender's domain with restriction classes of
postfix and pass a message to dedicated smtp process where
smtp_destination_concurrency_limit is not limited ?

May be there is way to force qmgr to select messages from the domain in
first place when it takes messages from queue for delivery ?


Best,
Deniss
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Wietse Venema
Deniss:
> I looking for a way to speed up delivery for specified sender's domain
> when incoming queue is overloaded.

Wietse
> When the road to the airport is clogged, everyone has to wait.
> [using] a different queue is like building a different road.
> Then, one road will hopefully not be congested.
 
Deniss:
> well, I want fast lane for certain domain indeed.

Then you need that second queue. Use smtp_fallback_relay
to move 'slow' mail out of the main queue.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Wietse Venema
Wietse Venema:

> Deniss:
> > I looking for a way to speed up delivery for specified sender's domain
> > when incoming queue is overloaded.
>
> Wietse
> > When the road to the airport is clogged, everyone has to wait.
> > [using] a different queue is like building a different road.
> > Then, one road will hopefully not be congested.
>  
> Deniss:
> > well, I want fast lane for certain domain indeed.
>
> Then you need that second queue. Use smtp_fallback_relay
> to move 'slow' mail out of the main queue.

If you must use a single queue, then you will have to increase the
active queue size so that it can absorb the full content of a peak.
This will increase the memory usage by the queue manager.

The default is:
    qmgr_message_active_limit = 20000

How large you can go is system-dependent. Try 10x.

Second, adding a dedicated master.cf transport for the domain will
reduce scheduling competition.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Viktor Dukhovni
In reply to this post by Deniss

> On Aug 25, 2017, at 5:24 AM, Deniss <[hidden email]> wrote:
>
> I have postfix as frontend to absorb incoming messages as fast as possible.
> Then I have slow smtp backend.
> Postfix limits delivery to backend with
> smtp_destination_concurrency_limit = 2
> This works pretty fine allowing to not oveload backend on peaks -
> messages become queued at frontend and delivered with some delay to backend.
>
> But now I want to deliver certain domain with no delay.
>
> Is it possible to catch the sender's domain with restriction classes of
> postfix and pass a message to dedicated smtp process where
> smtp_destination_concurrency_limit is not limited ?

For messages in the active queue the queue manager fairness
strategy for messages that share a common transport is
FIFO with intermittent preƫmption (messages with many
recipients are periodically preƫmpted by later messages
with fewer recipients).  At a higher level message delivery
across transports is round-robin.

So you can make "high-priority lanes" in the active queue,
by segregating a small portion of the traffic onto a separate
transport, with sufficient concurrency to handle that load
without delays at the expected peak loads.

> May be there is way to force qmgr to select messages
> from the domain in first place when it takes messages
> from queue for delivery?

However that strategy only works so long as the active
queue is not full.  That is, so long as the active queue
can fully absorb any sustained peak loads in the "low
priority" traffic.  If you have sufficient RAM to hold,
say, a million message envelopes in memory (if that's
the expected volume of your message buffer bloat for
the slow destination) then size the "active" queue
accordingly, and keep your "incoming" queue essentially
empty at all times.

The queue manager does not know what's the "incoming"
queue, those are just files on disk.  That's how the
queue manager manages to run in bounded memory.  So
prioritized scheduling (multiple lanes at the airport)
only works while the incoming queue (road to the airport)
is drained promptly and is not congested.

Once the incoming queue is congested everybody waits.

Another way to deal with a slow destination is to
drain in quickly to a second Postfix instance, where
the incoming queue may grow large, but you won't care
(you may want to zero in_flow_delay on the receiving
side).  Then the input Postfix will never have a
large active queue and can handle high priority
traffic promptly.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Deniss
In reply to this post by Wietse Venema
On 2017.08.25. 14:45, Wietse Venema wrote:

> If you must use a single queue, then you will have to increase the
> active queue size so that it can absorb the full content of a peak.
> This will increase the memory usage by the queue manager.
>
> The default is:
>     qmgr_message_active_limit = 20000
>
> How large you can go is system-dependent. Try 10x.
>
> Second, adding a dedicated master.cf transport for the domain will
> reduce scheduling competition.
>

Thanx, this looks useful
Should config looks like following ?

smtpfast  unix  -       -       n       -       -       smtp
  -o default_destination_concurrency_limit = 20

qmgr_message_active_limit = 200000
relay_domains = mydomain.com
relay_transport = smtp:backendsender_dependent_relayhost_maps = inline:{
prioritysender.com=smtpfast:backend }
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Viktor Dukhovni
On Fri, Aug 25, 2017 at 05:55:56PM +0300, Deniss wrote:

> Thanx, this looks useful
> Should config looks like following ?
>
> smtpfast  unix  -       -       n       -       -       smtp
>   -o default_destination_concurrency_limit = 20

No.  Rather:

    master.cf:
        smtpfast  unix  -       -       n       -       -       smtp

    main.cf:
        smtpfast_destination_concurrency_limit = 20

The destination concurrency limit is a qmgr(8) parameter, not a
delivery agent parameter.

> qmgr_message_active_limit = 200000

Yes, but ...

> relay_transport = smtp:backend

On MX gateway hosts that receive inbound mail, use "relay:..." not
"smtp:..." for your relay transport, and let outbound mail from
your system use "smtp".  This reduces contention between inbound
and outbound traffic, in particular slow outbound mail will not
delay inbound mail.

> relay_domains = mydomain.com
> sender_dependent_relayhost_maps = inline:{prioritysender.com=smtpfast:backend }

No, because sender_dependent_relayhost_maps (unsurprisingly) only
changes the relayhost, not the transport.  If your priority is by
origin, and not by destination, you may have to use three Postfix
instances, with low priority traffic shunted to the default slow
instance, and high priority traffic to the fast instance, with the
front end instance acting as a switch to separate the two flows.

Ultimately Postfix transport selection and concurrency limits are
(correctly) destination based, so to implement sender-dependent
behaviour you need to split the flow by sender, which can only be
done by handling off to another MTA (instance) with sender-dependent
relay settings.

You could use:

    http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps

but only when the destination domain is not a "relay" domain or
similar, that is, only if mail for the destination in questin just
goes whereever the MX records point with no transport overrides
beyond (sender_dependent_default_transport_maps) which selects a
sender dependent *default* transport.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Deniss
On 2017.08.25. 18:20, Viktor Dukhovni wrote:

>
> Yes, but ...
>
>> relay_transport = smtp:backend
>
> On MX gateway hosts that receive inbound mail, use "relay:..." not
> "smtp:..." for your relay transport, and let outbound mail from
> your system use "smtp".  This reduces contention between inbound
> and outbound traffic, in particular slow outbound mail will not
> delay inbound mail.
>
>> relay_domains = mydomain.com
>> sender_dependent_relayhost_maps = inline:{prioritysender.com=smtpfast:backend }
>
> No, because sender_dependent_relayhost_maps (unsurprisingly) only
> changes the relayhost, not the transport.  If your priority is by
> origin, and not by destination, you may have to use three Postfix
> instances, with low priority traffic shunted to the default slow
> instance, and high priority traffic to the fast instance, with the
> front end instance acting as a switch to separate the two flows.
>
> Ultimately Postfix transport selection and concurrency limits are
> (correctly) destination based, so to implement sender-dependent
> behaviour you need to split the flow by sender, which can only be
> done by handling off to another MTA (instance) with sender-dependent
> relay settings.
>
> You could use:
>
>     http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
>
> but only when the destination domain is not a "relay" domain or
> similar, that is, only if mail for the destination in questin just
> goes whereever the MX records point with no transport overrides
> beyond (sender_dependent_default_transport_maps) which selects a
> sender dependent *default* transport.
>

I'm using permit_auth_destination and it does not play without
relay_domains.

well, looks like I found few solutions:

1. change transport using FILTER via check_sender_access in
smtpd_sender_restrictions - fine until there is no other filter action
2. alter nexthop with sender_dependent_relayhost_maps - require
additional address on the backend

As I understand concurrency limits will differ from ones on default
route in both cases.

IMO it may be useful to allow alter transport in
sender_dependent_relayhost_maps as well in future releases of postfix


Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Viktor Dukhovni
On Mon, Aug 28, 2017 at 04:46:19PM +0300, Deniss wrote:

> > You could use:
> >
> >     http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >
> > but only when the destination domain is not a "relay" domain or
> > similar, that is, only if mail for the destination in questin just
> > goes whereever the MX records point with no transport overrides
> > beyond (sender_dependent_default_transport_maps) which selects a
> > sender dependent *default* transport.
>
> I'm using permit_auth_destination and it does not play without
> relay_domains.

If the destination domain is yours and the senders are remote
untrusted clients, then indeed "default_transport" won't do
unless you're a backup MX host (in that case it is possible
to allow relaying for the domain via "check_recipient_access",
and the default transport will find the right primary MX host).

> well, looks like I found few solutions:
>
> 1. change transport using FILTER via check_sender_access in
> smtpd_sender_restrictions - fine until there is no other filter action

This would be wrong for multi-recipient email when some recipients
are local, or in any case should not be sent to the same destination.

> 2. alter nexthop with sender_dependent_relayhost_maps - require
> additional address on the backend

This has no effect on concurrency limits, but with a different
nexthop you get a new pool of concurrency slots, so if traffic to
that destination is light and the active queue is not full, that
will help avoid queueing behind a other traffic that is sharing a
low-throughput channel.

> As I understand concurrency limits will differ from ones on default
> route in both cases.

Not differ, just be separate.

> IMO it may be useful to allow alter transport in
> sender_dependent_relayhost_maps as well in future releases of postfix

No, that would not be a good idea, since transport selection needs to
be recipient based.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Deniss
On 2017.08.28. 17:36, Viktor Dukhovni wrote:

>>> but only when the destination domain is not a "relay" domain or
>>> similar, that is, only if mail for the destination in questin just
>>> goes whereever the MX records point with no transport overrides
>>> beyond (sender_dependent_default_transport_maps) which selects a
>>> sender dependent *default* transport.
>>
>> I'm using permit_auth_destination and it does not play without
>> relay_domains.
>
> If the destination domain is yours and the senders are remote
> untrusted clients, then indeed "default_transport" won't do
> unless you're a backup MX host (in that case it is possible
> to allow relaying for the domain via "check_recipient_access",
> and the default transport will find the right primary MX host).

I have domain + list of emails in the domain.
with relay_domains recipient's check stops just after foreign domain
name found as destination.
with check_recipient_access full email list scanned to reject foreign
domain.
Is this correct ?

>
>> well, looks like I found few solutions:
>>
>> 1. change transport using FILTER via check_sender_access in
>> smtpd_sender_restrictions - fine until there is no other filter action
>
> This would be wrong for multi-recipient email when some recipients
> are local, or in any case should not be sent to the same destination.

not the case for relay box

>
>> IMO it may be useful to allow alter transport in
>> sender_dependent_relayhost_maps as well in future releases of postfix
>
> No, that would not be a good idea, since transport selection needs to
> be recipient based.

what is the difference to default_transport
/sender_dependent_default_transport_maps ?

Why relayhost/sender_dependent_relayhost_maps do not work same way - not
include transport as well ?
Reply | Threaded
Open this post in threaded view
|

Re: prioritization in qmgr scheduler

Viktor Dukhovni
On Mon, Aug 28, 2017 at 05:53:11PM +0300, Deniss wrote:

> > If the destination domain is yours and the senders are remote
> > untrusted clients, then indeed "default_transport" won't do
> > unless you're a backup MX host (in that case it is possible
> > to allow relaying for the domain via "check_recipient_access",
> > and the default transport will find the right primary MX host).
>
> I have domain + list of emails in the domain.  with relay domains
> recipient's check stops just after foreign domain name found as destination.
> with check_recipient_access full email list scanned to reject foreign
> domain.  Is this correct ?

Indeed relay_recipient_maps validates relay recipients, but with
the "default" address class you'd have to explicitly implement
recipient checks.

    main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_relay_restrictions =
            check_recipient_access ${indexed}relay-rcpts

        smtpd_recipient_restrictions =
            check_recipient_access ${indexed}valid-rcpts
            ... anti-spam restrictions ...

    relay-rcpts:
        example.com  OK

    valid-rcpts:
        [hidden email] DUNNO
        [hidden email] DUNNO
        ...
        [hidden email] DUNNO
        example.com  REJECT 5.1.1 Recipient address unknown

This may or may not be worth the effort.

> >> 1. change transport using FILTER via check_sender_access in
> >> smtpd_sender_restrictions - fine until there is no other filter action
> >
> > This would be wrong for multi-recipient email when some recipients
> > are local, or in any case should not be sent to the same destination.
>
> not the case for relay box

If the relay box sends *ALL* recipients to the same destination,
except for internally-generated email (bounces, postmaster notices)
which are not subject to content_filters, then you may be able to
get away with a sender-based "FILTER" access(5) table entry.

[ Keep in mind that setting "relayhost" may interfere with bounce
  delivery, if the relayhost is an inbound relay only.  The correct
  way to set an inbound relay is either of:

        relay_transport = relay:[nomx.example.com]
        relay_transport = relay:mx.example.com
]

> >> IMO it may be useful to allow alter transport in
> >> sender_dependent_relayhost_maps as well in future releases of postfix
> >
> > No, that would not be a good idea, since transport selection needs to
> > be recipient based.
>
> what is the difference to default_transport
> /sender_dependent_default_transport_maps ?

The 'default' transport does not preempt explicit transport selection,
either by address class or transport table.

> Why relayhost/sender_dependent_relayhost_maps do not work same way - not
> include transport as well ?

I'm afraid you'll have to figure that out over time.

--
        Viktor.