> > > OK, sorry again. I had assumed because you can turn off header checking >by
> > > using receive_override_options, you could also override (change) them. > > > > It is possible to override header_checks by defining a > > different cleanup_service_name for smtpd, then defining that > > cleanup service with a header_checks override. This can get > > pretty messy, you can find examples in the list archives. > > > > The better solution is to use multiple instances. All postfix > > versions support multiple instances. Newer versions include > > tools to make multiple instance creation/maintenance easier. > > He seems to want sender IP address selection based on some message > attribute. We discussed that early 2010 in > http://www.irbs.net/internet/postfix/1001/0390.html > > I solved this specific problem a few days later with Postfix 2.7 > by changing the effect of "FILTER transport:" (i.e. transport > without next-hop destination). > > The OP appears to be stuck on Postfix 2.3 so he will have to use > the solution that involves specifying "FILTER smtp:nexthop" where > each nexthop is a separate Postfix instance with its own myhostname > and inet_interfaces setting. Well, I started a new thread because I actually have a separate requirement to add a custom header. That said, I *am* trying to address the issue you so eloquently explain as well. What I ran into while solving the add-a-header issue (see my last post on this thread) was that I can use a FILTER action from a smtpd_*_restriction check to select a specialized smtp process that is bound to a given IP address. I found, however, that the FILTER action's nexthop field could not be left blank (without a colon, the action is ignored; with a colon but nothing after it, I got name service errors in my mail log). The hack to resolve that seemed to be to change the restriction check to be check_client_access so I could get at the recipient email address and parse off its domain to hand to the FILTER nexthop field. But I'm not sure what the implications of this are. Am I assuming that the MX for any recipient address is hosted at the same domain? Or does postfix still do the needed lookups for me? Testing this, it does seem to work OK, but are there other issues that this raises? Here is what I have. Apologies if this is a Bad Idea. master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o smtpd_helo_restrictions= -o smtpd_client_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_client_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 > In the 2010 discussion I forgot to mention that he'd also have to > change the inet_interfaces setting of the primary Postfix instance > to avoid "mail loops back to myself" errors. To fix this, specify > "inet_interfaces = 127.0.0.1 1.2.3.4" where 1.2.3.4 is the primary > IP address. This way, the primary instance won't try to receive > mail for the additional instances. Thanks for the detailed information about how to try solving this with a secondary postifx instance. If my solution above really is a Bad Idea, I think short of upgrading, this is where we are headed. The information you've provided is highly appreciated.