> > 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. Fair enough. > This quote from RELEASE_NOTES-2.7 describes two solutions that may > be of interest: see Feature 20100117 and Feature 20091209 below. Yes, especially feature 20100117. Thank you very much for your work on those new features. Unfortunately, I'm stuck with version 2.3.3 (bah! yum!), so I've been trying to find other ways to accomplish this. I thought I might be able to override transport_maps (or default_transport?) in a smtpd process that gets mail back from the content filter, but I have been educated that this is not possible (see thread "Multiple transport maps in master.cf?"). Anyone have any other tricks up their sleeve that could address this (beside multiple instances)? It looks like if I can make the smtpd process add some kind of special header (is this possible?), then maybe I can do what was done here: http://marc.info/?l=postfix-users&m=113351892721907&w=2 Is that work-able? - smtpd add a custom header - define a header check that detects the special header and filters those messages off to a special smtp process (and hopefully remove the special header, but OK if not) > 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. > > 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. >
