On 05/07/2012 08:15 PM, Viktor Dukhovni wrote:
On Mon, May 07, 2012 at 10:04:21PM -0500, Noel Jones wrote:

We have some fairly involved routing requirements, and have been
using a script that creates a transport table from a number of
source files. It's been working well for some years, but now we have
a need for sender-dependent transport rules. We periodically creates
the sender_dependent_default_transport_maps, which appeared to work
perfectly, but then we discovered that the transport table overrides
sender-dependent transport - exactly as documented.

We have a requirement for sender-dependent transport rules that
override everything else. I thought of setting up another postfix
instance just to handle the sender-dependent transport before
handing it off to either the current smtp server or one of the
designated transports, but it seems like overkill. Is there any
other way to make sender_dependent_default_transport_maps take
priority over the transport table?
The transport priority order is not configurable.

I suppose you could use a check_sender_access map that returns
FILTER transport:nexthop for the target senders.  Note this solution
is only useful with mail submitted via SMTP and is incompatible with
an after-queue content_filter (unless you do some master.cf gyrations).
It also breaks mail routing on any real MTA that needs to route
different recipients to different destinations. The only real
use-case for sender-dependent routing is on shared laptops and
home machines where all of a user's initially submitted mail
is relayed via that user's ISP, but then one just empties
out the transport table and voila, the default transport wins.

My advice to the OP would be to separate the sender-dependent
traffic onto a separate MTA that does no (normal) recipient
dependent routing.

Thanks for the sage advice - After some consideration and a bit of testing I think we finally have a reason for going to a multi-instance postfix configuration. It's either that, or spin up a new server to handle sender-dependent transport, and our support organization charges by the server, so postmulti seems to be the best option.

Joe






Reply via email to