> > > 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.

Reply via email to