> > >>> Here is what I've done with the typo corrected. Is this a Bad
> > >>> Idea? Are there problems with naively using the domain from the > > >>> recipient email address as the > > >>> nexthop value? > > >>> > > >>> 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_recipient_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 > > >> > > >> This sends all mail to transport "smtp2". If that is what you want, > > >> then you can get a better result with "default_transport = smtp2", > > >> > > >> You can get a simpler result by adding "-o smtp_bind_address..." > > >> to the default "smtp" delivery transport. > > > > > > Sorry, the smtpd listener on port 10024 only gets *some* of the mail on >the > > > server. There is another smtpd listener on a different port that I >didn't > > >show > > > that does not use the "smtp2" process to send mail. Thus, only the > > > mail > > >that I > > > route into the smtpd listener on port 10024 is sent via the IP address > > > bbb.bbb.bbb.bbb. > > > > > > So it does seem possible (and reasonably simple) to achieve this > > > feature, > > >but > > > I'm still keen to know if there are any Bad Ideas lurking with this >scheme. > > > > > > Some problems lurking in the shadows ... > > > > Routing mail with smtpd_recipient_restrictions and FILTER will > > give inconsistent results with multi-recipient mail. The > > FILTER action is a per-message setting -- the last recipient > > domain sent will be the one filtered on. Using a transport > > table and multiple postfix instances is the only reliable > > solution. > > > > In smtpd_data_restrictions, multiple recipients are undefined. > > If the message contains multiple recipients, no recipients > > information will be available in smtpd_data_restrictions. > > Ah ha! Indeed, testing multiple recipients, it seems to quietly fall back > to > > the default smtp process for sending, which is exactly the behavior I was >seeing > > when the FILTER was specified without the colon (Wietse noted that it > *should* > > have been trying to send via $myhostname, but in my version, for whatever > reason, I'm seeing different behavior). > > While there are some minor unexplained bits, this makes enough sense. So > this > > scheme isn't going to work 100%. Looks like it WOULD work with two minor > changes: > > 1) start a separate instance which is fairly dumb/basic, just ready to send >mail > > normally that it gets from this FILTER action > > 2) change the FILTER action to this: > > /^/ FILTER smtp2:second.postfix.instance.example.com I've just finished implementing this and it's working nicely. Hopefully I've pleased everyone who kept telling me to use multiple instances. :-) This seems to be the only way to do this, at least if I stay with version 2.3.3. > However, you noted that when you have multiple recipients, > smtpd_data_restrictions won't have any recipient data. Does that mean even >/^/ > > will not match? If I change smtp_data_restrictions to use > check_client_access > > instead, can I rely on it to *ALWAYS* have at least *something* there > (doesn't > > matter what, since I'm matching on /^/)? If not, should I try something > like > check_client_mx_access? This was in fact still an issue - when sending to multiple recipients, the regular expression failed to match anything since there's nothing there apparently, so I changed it to check for check_client_access and so far, that seems to always have something in it, so the regular expression matches and the mail goes where it should. Now just have to spend some time with the second instance to trim it down and make sure it's not doing stuff it doesn't need to, etc. (any hints on where to find minimalist process list for master.cf for instances that ONLY accept from another process on localhost and send mail out? Is the default master.cf about as trimmed down as I can go?). Thanks again.
