I hope the message quoting/formatting in my response works as expected. If not let me know and I will rely less on gmail's formatter.
> > "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). > Sure. I tried to understand it that way. However, there are at least two problems: (1) Let's look at this definition "relay_transport: The default mail delivery transport and next-hop destination for remote delivery to domains listed with $relay_domains. In order of decreasing precedence, the nexthop destination is taken from $relay_transport, $sender_dependent_relayhost_maps, $relayhost, or from the recipient domain. This information can be overruled with the transport(5) table." If a user reads that and then goes to read transport(5) it is not at all obvious that the sentence "This information can be overruled with the transport(5) table" means "The relay_transport is overruled by the mappings specified in $transport_maps" (2) transport(5) seems to list tables that override tables listed in relay_transport, but those overriding tables are not listed in relay_transport. So what is the precedence relationship in that case? In other words, I was scratching my head thinking "is this bad english referencing the general concepts in transport(5) or should I be trying to find the specific tables listed there that this could be in reference to" or what? If I understand it well enough I'll write and submit a doc PR. > 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. > If I put all this together what I think I'm hearing is that transport_map overrides everything but if nothing matches there, or it's not specified, then some of those other settings may trigger. E.g., if I have a transport_map defined, but the destination domain doesn't match anything in it, then if this is a message that's being relayed, postfix will look at the sender dependent map etc... > > 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. > So does sender_dependent_relayhost_maps contain mappings from keys to transport:nexthop values or to nexthop values? I think what's generally missing in the transport(5) man page and any docs I've read so far, is a description of the concept that what postfix is trying to do is to get to a fully resolved transport:nexthop PAIR. Some of the settings can specify only the transport or both the transport:nexthop or only the nexthop. As soon as it's fully resolved or hit DUNNO, the search stop. Do I have that right? > 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). > I'm still left unsure as to whether there are differences in how the sender dependent tables are searched vs the non-sender dependent tables; however, I think the only reason for my confusion is that there is now misinformation out there that comes up whenever people google these topics. My guess is that if you want to match all relayed mail from bad_domain.com even if you put that rule into one of the sender dependent maps, the key is bad_domain.com or .bad_domain.com and never @bad_domain.com. The counterexample could be included in the man page/docs given the possible confusion. E.g. "@somedomain.com will never match anything. Leave the @ out." If that's true, a check for such keys during startup could issue warnings. [my examples and your explanations] > Thank you, I understood. > the sender_transport_maps contains: > > @filtered_domain.com DISCARD > Ok. So this did not result in an error not only because my transport_map caused no further search to be done, but also because DISCARD or discard would just be interpreted as a "nexthop name" when encountered in that map. While not technically an error, again, a startup sweep of these maps could at least issue warnings for common misconfigurations like this one. That being said, I suppose there could be a "blackhole" transport that sends everything to /dev/null, and then (assuming the sender specific maps can override any already resolved transport), the map could contain an . bad_domain.com => blackhole:foobar mapping, where foobar is irrelevant but servers to stop the search for a nexthop. Right? "DISCARD" is access(5) verb, not a transport. And should be used with > "check_sender_access" in one of "smtpd_mumble_restrictions" lists. > Thanks, I'll look into these. My goal is to silently discard all inbound mail from a certain domain. Or actually, I may wish to redirect all of that mail either to a flat file (similar to the proposed blackhole transport) or to a "dead letter" mailbox on some nexthop. This would require rewriting the delivery address I guess? Thank you!
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
