> >>> 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
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?
Thank you!
