> > OK, thank you very much for the pointer to smtp_bind_address. That's what > > I >
> > need, but I'm stumbling at the transport map. I already have outgoing > > mail > > segregated how I want it when it exits my content filtering (ready to be >sent > > > out). So ideally, the content filter (actually the specialized smtpd >process > > > that accepts mail from the content filter) could hand off to a specific > > smtp > > > process that has the needed smtp_bind_address. > > The smtpd process does not choose the smtp process. > > This quote from RELEASE_NOTES-2.7 describes two solutions that may > be of interest: see Feature 20100117 and Feature 20091209 below. > > Feature 20091209 triggers only on the envelope sender address, > while Feature 20100117 can trigger on any message property including > a string in the header or body. I ended up staying (for now) with my outdated version 2.3.3 but still found a solution in creating a secondary instance of postfix that accepts the mail that I wanted to have sent on my other network interface. The main instance uses a smtpd_data_restriction/check_client_access FILTER action to send the needed mail to the secondary instance. Just for the sake of the mailing list archives, this thread is more or less continued in one I started with the subject "Multiple transport maps in master.cf?" on the next date and then more seriously in a thread I started with the subject "header_checks in master.cf?" on the same date. Thanks to all. > Both require that mail is split into classes, and all mail in class > X is sent out from an SMTP client IP address that is reserved for > class X. For each class you configure master.cf one Postfix SMTP > client for each SMTP source IP address, where each client has its > own "-o myhostname" and "-o smtp_bind_address" settings. > > /etc/postfix/master.cf: > smtp1 unix - - n - - smtp > -o smtp_bind_address=192.168.1.1 -o myhostname=hostname1 > smtp2 unix - - n - - smtp > -o smtp_bind_address=192.168.1.2 -o myhostname=hostname2 > > With Feature 20100117 you'd specify actions of "FILTER smtp1:" or > "FILTER smtp2:" in an smtpd access(5) table, header_checks(5) or > body_checks(5). For example, in an access table: > > /etc/postfix/main.cf: > smtpd_sender_restrictions = > check_sender_accesss hash:/etc/postfix/sender_access > > /etc/postfix/sender_access: > sender1 FILTER smtp1: > sender2 FILTER smtp2: > > With Feature 20091209 you'd have: > > /etc/postfix/main.cf: > sender_dependent_default_transport_maps = > hash:/etc/postfix/sender_transport > > /etc/postfix/sender_transport: > sender1 smtp1 > sender2 smtp2 > > Wietse > > Major changes - sender reputation > --------------------------------- > > [Feature 20100117] The FILTER action in access maps or header/body_checks > now supports sender reputation schemes that dynamically choose the > SMTP source IP address. Typically, mail is split into classes, and > all mail in class X is sent out from an SMTP client IP address that > is reserved for class X. > > This is implemented by specifying FILTER actions with empty next-hop > destinations in access maps or header/body_checks, and by configuring > in master.cf one Postfix SMTP client for each SMTP source IP address, > where each client has its own "-o myhostname" and "-o smtp_bind_address" > settings. > > [Feature 20091209] sender_dependent_default_transport_maps, a > per-sender override for default_transport. The original motivation > is to use different output channels (with different source IP > addresses) for different sender addresses, in order to keep their > IP-based reputations separate from each other. > > The result value syntax is that of default_transport, not transport_maps. > Thus, sender_dependent_default_transport_maps does not support the > special transport_maps result value syntax for null transport, null > nexthop, or null email address. >
