Patrik Rak:
> Hello,
>
> Some time ago I was setting up yet another postfix deployment, and I was
> once again thinking about the case when (temporarily) undeliverable
> recipients block most or all of the available delivery agents.
Low-level comments:
- What common use case has different per-recipient (not: per-sender,
etc.) soft reject rates for a mail stream between two sites? Does
it matter whether some portion of a mail stream between two sites
is deferred because of the recipient, sender or other cause?
- Postfix has multiple transports configured: the required ones
such as local_transport (local), default_transport (smtp),
relay_transport (relay), plus the ones that aren't selected with
$local/virtual/relay/default_transport such as retry, error, and
ad-hoc transports. It would be wrong to hard-code the "alternate
retry transport" feature to just one transport. Even if it were
used only with smtp-like transports, there may be more than one.
- Postfix tries to play "nice" by not overwhelming remote servers
with many connections. This is scheduled per transport, not across
transports. I'm not claiming that Postfix concurrency scheduling
solves all problems, but having two transports sending to the same
destination would complicate things a little (but no more than
having sender-dependent source IP addresses).
Wietse
> In enterprise environments this problem has been traditionally solved by
> using the fallback_relay feature to pass these recipients to standalone
> postfix server (or at least separate instance). This is perhaps not going
> to change, as on high traffic sites such recipients can clog not only the
> available delivery agents, but the entire active queue as well.
>
> However, on medium traffic sites, I was thinking that there might be a
> more convenient solution which would not require standalone server or
> multi-instance setup. The idea is that qmgr could automatically use
> different transport for recipients from the deferred queue (as opposed to
> those coming from the incoming queue). This wouldn't eliminate the active
> queue bottleneck, but other than that it would keep the retried recipients
> out of the way of the new ones entirely. We have already used similar
> approach in the past to separate the inbound and outbound recipients by
> introducing the relay transport class, for example.
>
> Configuration wise, it might work like this:
>
> - in master.cf, clone the smtp transport, call it "slow" for example
> - in main.cf, set smtp_retry_transport = slow
>
> Implementation wise, the following changes would be necessary:
>
> - when creating message structure, qmgr would need to keep track
> if it came from the incoming or deferred queue
> - in qmgr_message_resolve(), just before looking up the transport,
> when the message originates from deferred queue, qmgr would
> replace the transport name in the reply with the configured retry
> variant if it is defined and such transport exists.
>
> What do you think? Is it an idea worth implementing?
>
> Patrik
>
