Hi Viktor! On Mon, Mar 15, 2021 at 5:23 PM Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> Transport lookups in smtpd(8) are just for recipient classification and > validation, so that it can distinguish between local, virtual alias, > virtual mailbox, relay recipients and the rest. No actual routing > happens in smtpd(8). Thanks for clarifying this, it is how I suspected. > > .. now where the transport_maps entry to the next hop is resolved? > > Is that in the qmgr? > > Naturally, the queue manager is responsible for handling off message > envelopes to the various delivery agents. There's only one queue > manager, which limits your choices to "content_filter", or custom > rewriting in a dedicated per-smtpd(8) cleanup(8) service. I'm conceptually still stuck a bit on this, but I'm probably just missing a tiny piece so far - or something huge, that I cannot implement the thing as I had planned. We have a central, internal mail dispatching system, after all the content filtering etc. which processes inbound and outbound emails. The challenge I have now is that all messages from applications (which are concentrated on a different class of servers before as well) to the backend mail servers need to be delivered to a different port on the backend mail servers. Mail from applications to external recipients need to be delivered to the regular smart host. All other mail to the backend mail servers needs to be delivered on the regular port. So I have these three classes of routing: Application to internal recipient -> app mail concentrator -> mail central -> backend with special port Application to external recipient -> app mail concentrator -> mail central -> regular outbound smarthost Any other mail to internal recipient -> mail central -> backend My thought was now to add a special X-Header on the app mail concentrator, which changes the routing decision on the mail central. But if I add the header to all mails, and use a generic header_check to set a FILTER action for that header, I am actually not routing the external mails to the smarthost anymore, but also to the internal backend, which obviously does not work. >From what I understand, when I give it into the smtp transport, all routing decision has already been made, so I cannot change the nexthop with a header_check in the smtp transport anymore (even though I only want to change the port - but I guess it is the same difference). Can I somehow define something on a header that a different transport_map is applied? I will make sure that that X-header is only ever added on the inside, and is filtered on any ingress point into our mail infrastructure. Any help on this is appreciated! Best regards, Jens
