(no email)
Date: Sun Jun 02 2002 - 23:25:06 EDT
On Mon, 3 Jun 2002, Craig Sanders wrote:
> On Sun, Jun 02, 2002 at 05:33:22PM -0400, Wietse Venema wrote:
> > A fall back transport table?
>
> something like that.
>
I think that Wietse is on the right track, I was thinking about a
multi-valued transport table, his suggestion of multiple tables is
logically equivalent, but substantially simpler and cleaner.
The queue manager would need to try the fallback transport table before
putting mail in the deferred queue.
The selected fallback transport would in the general case need to be
destination dependent, so a (fallback) transport table is more appropriate
than the suggestion below:
> smtp_fallback_transport deadbeats:
> or
> smtp_fallback_transport uucp:upstream_node
> or
> bsmtp_fallback_transport smtp:
> or
> uucp_fallback_transport error:uucp subsystem misconfiguration
>
So how useful would having the queue manager try a fallback delivery
agent before deferring a message be? One immediate problem this could
solve is moving deferred mail out of the primary mail queue (possibly
freeing space on that precious SSD) in cases where the deferral is due to
a remote 4XX response rather than a failure to connect (which is handled
via fallback_relay).
Any other compelling applications?
-- Viktor. - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|