Oh, sorry, one last (lol) thing ... since it doesn't seem like "@" is ever part of searches do you think it might be wise to change the docs so that instead of saying " sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain"
they say "The tables are searched by the envelope sender address (i.e. full user@domain), as well as the domain part alone." It's not clear what distinction is being made by the original text, otherwise ... and the original text seems to imply the @ is included, whereas the docs at transport(5) contradict that implication, leaving users having to battle with google disinformation. On Sat, Apr 22, 2023 at 6:45 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users > wrote: > > > "This information is overruled with... the transport(5) table." > > In other words, "transport_maps", a logical dictionary built from > a list of component tables (some of which may also be composite). > > > But "sender_dependent_relayhost_maps" indicates that it can be overruled > by > > "sender_dependent_default_transport_maps" > > Bottom line "relayhost" and its sender-dependent versions provide a > non-default nexthop to override the recipient domain, but may in turn be > preëmpted by any explicit nexthop in the transport(5) map, whether > global, or sender-dependent. > > > > so there is apparently some relationship between relay_transport and > > default_transport or at least between the sender_dependent files > > amongst themselves????? > > All that's going on is that "bare" transports get their nexthop from > either the recipient domain, or some sort of relayhost override, while > complete "transport:nexthop" pairs do not. > > > The transport(5) docs contain examples that indicate domains are searched > > without the @ sign, but in other places and in examples I find online it > > appears the @ sign is included in the sender_dependent...* searches??!! > > The transport(5) table supports per-recipient lookups (user@domain) or > just per-domain lookups (I don't recommend reliance on per-recipient > transport tables except perhaps for a small set of "special" users, the > majority of transport decisions should be domain-wide). > > > relay_domains = domain1.com domain2.com domain3.com > > Postfix will inbound mail for these domains from any sender. > > > transport_maps = hash:/etc/postfix/transport > > This trumps all other transport choices, and also nexthop choices when > specified. > > > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_transport_maps > > This overrides the nexthop for remote delivery, whenever the > transport(5) table does not. > > > the /etc/postfix/transport map contains entries for each of the > domain1.com > > > domain1.com smtp:[domain1.mail.handler.com]:2000 > > domain2.com smtp:[domain2.mail.handler.com]:2020 > > These specify a nexthop, so not affected by relayhost, sender-dependent > or otherwise. > > > the sender_transport_maps contains: > > @filtered_domain.com DISCARD > > "DISCARD" is access(5) verb, not a transport. And should be used with > "check_sender_access" in one of "smtpd_mumble_restrictions" lists. > > Recipient and sender Domains are looked up in access(5) tables without a > leading "@". > > -- > Viktor. > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org >
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
