> > > > 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. > > The configuration makes absolutely no sense at all. Hmm, I'm not sure why you see *no* sense in it. If there are two smtpd listeners (that take mail from a content filter) on different ports, and the one I've shown uses this scheme to send via "smtp2" which is bound to another IP address (the one I didn't show just lets mail go via normal means, i.e. the default smtp process), isn't there some logic there? I already have the mail I want to send on a different IP address/network interface segregated by the time it gets to the content filter, so this scheme seems to do what I need. > I also have > enough of this game where you reveal a tiny piece of the puzzle at > a time. My sincerest apologies. Wietse, the last thing I'd like to do is frustrate you (or any others who've been so kind to indulge me here). I was merely trying to reduce confusion by eliminating the parts of master.cf that are not related to what I'm trying to do. Say for the sake of clarity, I have two groups of users. I wish to keep mail sent by each group separate (sent on different network interfaces). If I have a webmail system that submits messages to postfix on a designated port number for each of these groups, then the separation is already achieved by the time Postfix sees the messages, so all I am trying to do is ensure Postfix can then route mail from one of those groups out of a different IP address. I showed the configuration for that portion of this scheme which begins when mail comes back from content filtering. All is well before this step, which is why I didn't believe it is relevant. If that's still clear as mud, I apologize again and I guess I'll live with what I've shown above, as it seems to be working fine so far, segregating my outgoing mail perfectly. Thanks for all you do and for the AWESOME software.
