Hi Angelo In the end the solution behind your link is what I already tried to achieve. But I cant only check for the destination (receiver) address. I need a combination of sender and receiver address to determine the transport which is to be used.
Regards, Patrick > On 22 Jun 2017, at 20:38, Fazzina, Angelo <[email protected]> wrote: > > Hi Patrick, > Not sure this is helpful but I searched the archives and found this. > > http://marc.info/?l=postfix-users&m=148063002508453&w=2 > > maybe brush up on the doc of transport config file options ? > > Good luck. > -ALF > > -Angelo Fazzina > Operating Systems Programmer / Analyst > University of Connecticut, UITS, SSG, Server Systems > 860-486-9075 > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Patrick Landolt > Sent: Thursday, June 22, 2017 2:29 PM > To: Postfix users <[email protected]> > Subject: Re: determine transport based on sender and receiver > > Thank you taking the time to answer my question. Unfortunately I have > no idea what you mean. May you point me to some documentation that > I can follow and understand your answer? > > Regards, > Patrick > > >> On 22 Jun 2017, at 17:28, Wietse Venema <[email protected]> wrote: >> >> Patrick Landolt: >>> I try to get a setup like to following ready: >>> >>> 1. I have multiple ip postfix should be able to send mails to other MTA >>> 2. I setup different transport in master.cf each with a smtp_bind_address >>> corresponding to a single ip >>> so far, so good! that setup already works >>> >>> But now I need to handle slow ISPs like yahoo etc. My first try is to add >>> transport_maps with like >>> yahoo.com slow: >> >> This requires support for multiple criteria, in this case sender >> and recipient. The only place that currently does this in Postfix >> is the SMTP server policy protocol, which is implemented before >> mail is queued. A sane implementation of what you want should be >> done post-queue. >> >> Strawman transport_policy: >> - The client is implemented in the trivial-rewrite service. >> - The protocol format is like the SMTP policy protocol: one line >> per name=value attribute. This easy to parse in any language. >> - The request contains one sender, one recipient, and perhaps other >> information. >> - The service replies with one transport, one nexthop, and one >> recipient. >> - Open question: how are the client requests placed in time relative >> to transport_maps, sender_dependent_mumble_maps, and other routing >> features? >> >> Wietse >
