Thanks Viktor:
> welcome to the internet
Yeah :) I've been here for 30 years.
> unlikely to be productive
I simply want to help others avoid my points of confusion, in the belief I
am not a uniquirely incapable or unintelligent reader.
I will say this: Irrespective of how well you understand postfix (as an
expert) the docs have clearly resulted in a lot of confusion not only in
me, but in others, as evidenced by erroneous alternative content that comes
up when searching this topic and/or similar questions asked by others in
other forums.
Unfortunately, precisely because the "welcome to the internet," it's often
a good idea to disambiguate demonstrated points of confusion and/or
counteract easily found internet misinformation about the project, directly
in the project docs.
> @
In your original response you were probably narrowly thinking about a
specific transport(5) map when you responded @ was not included in search,
but here unless I misunderstand you, you verify that there are some tables
where @domain.com is searched. In other words, you seem to agree the
components that have statements such as "The tables are searched by the
envelope sender address and @domain" do the table search differently than
described in transport(5).
Unfortunately, the doc for those components point readers to the
transport(5) doc but only mention the @domain item in passing, leaving
readers wondering about the semantics of that statement, given the examples
in transport(5) go counter to the statement. "@domain" could have been
written that way to highlight that "domain" refers to the part after the @
sign.
I suggest transport(5) include a small note in the table of search
examples/precedence to show examples relevant to the search order and for
those components that include the @ sign, or that their docs point to a
similar table specific to how search is performed for those components.
> [ DUNNO is access(5) not transport(5) ] [] indicate paraphrasing
The docs for sender_dependent_default_transport_maps seem to contradict
you.
They state "lookup result of DUNNO terminates the search without overriding
the global default_transport parameter setting." so either you are mistaken
or I am again misunderstanding either you or the docs.
> [no scans]
That makes sense for table formats that have indeterminate keys such as
pcre, but the objection IMHO makes less sense relative to *results* in
those tables. If an access(5) verb appears in a transport(5) result that
seems detectable. That being said, it turned out "discard", though not a
verb, *is* a valid transport that seems to be defined in default
distributions of postfix, and operates like my proposed "blackhole"
transport ... so that muddies the waters. Perhaps postfix should disallow
transport names that match verbs for that reason. I think transport names
are completely arbitrary, so doing that could avoid confusion.
Finally, to prevent long or expensive startup any proposed "config sanity
scans" could be limited by a timer or by a "total items scanned" counter.
and be either selected or squelched by command line arg. Then, if the scan
terminates early, it could generate a separate warning about "config sanity
scan terminated early due to table size."
Thanks again for your prior responses. I think I now understand things well
enough to make progress.
No need to respond unless you'd like to chat about this further.
On Sat, Apr 22, 2023 at 8:58 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:
>
> > If I understand it well enough I'll write and submit a doc PR.
>
> This is unlikely to be productive.
>
> > If I put all this together what I think I'm hearing is that transport_map
> > overrides everything
>
> The transport(5) table has the highest priority for the components of
> the (transport, nexthop) pair that it specifies. All the other sources
> are fallback sources when either or both of the transport or nexthop are
> not specified in transport(5).
>
> > So does sender_dependent_relayhost_maps contain mappings from keys to
> > transport:nexthop values or to nexthop values?
>
> A "relayhost" is a host (i.e. a nexthop) so clearly not a transport
> ("smtp", "lmtp", "local", ...).
>
> > 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.
>
> https://www.postfix.org/transport.5.html
>
> RESULT FORMAT
> The lookup result is of the form transport:nexthop. The
> transport
> field specifies a mail delivery transport such as smtp or local.
> The
> nexthop field specifies where and how to deliver mail.
>
> The transport field specifies the name of a mail delivery
> transport
> (the first name of a mail delivery service entry in the Postfix
> mas-
> ter.cf file).
>
> The nexthop field usually specifies one recipient domain or
> hostname.
> In the case of the Postfix SMTP/LMTP client, the nexthop field may
> con-
> tain a list of nexthop destinations separated by comma or
> whitespace
> (Postfix 3.5 and later).
>
> ...
>
> > 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.
>
> No. "DUNNO" is an access(5) verb, but is NOT applicable in the case of
> transport(5) lookups (it does apply in the sender-dependent table to
> support creating NOP exceptions to broad rules). Access control !=
> routing.
>
> > Do I have that right?
>
> Not quite. See above.
>
> > 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,
>
> Barring minor oversights, each Postfix table-based feature documents the
> lookup keys searched and the result format.
>
>
> https://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
>
> A sender-dependent override for the global relayhost parameter
> setting. The tables are searched by the envelope sender address and
> @domain.
>
> This is slightly different from transport(5) where domains are matched
> without a leading "@", as documented.
>
> > I think the only reason for my confusion is that there is now
> > misinformation out there that comes up whenever people google these
> topics.
>
> Search engines index "relevant" information, that appears to be popular,
> but accuracy isn't necessarily part of the equation. Welcome to the
> Internet.
>
> > 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 lookup key formats for the various mumble_maps parameters are as
> documented. Consult the https://www.postfix.org documentation.
>
> > > > 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.
>
> You said "sender_dependent_transport_maps",
>
>
> https://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
>
> A sender-dependent override for the global default_transport
> parameter setting. The tables are searched by the envelope sender
> address and @domain. A lookup result of DUNNO terminates the search
> without overriding the global default_transport parameter setting.
> This information is overruled with the transport(5) table.
>
> > While not technically an error, again, a startup sweep of these maps
> could
> > at least issue warnings for common misconfigurations like this one.
>
> Postfix doesn't "sweep" maps. They could be large, or could be regexp
> based, ... Map lookups are performed on demand, one key at a time.
>
> > 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?
>
> There's a "discard" transport, to which specific recipient domains can
> be delivered (post-queue discard). There is also a "DISCARD" access(5)
> verb which causes the entire message to be discarded "pre-queue".
>
> > > "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.
>
> For that, use acces(5):
>
> main.cf:
> parent_domain_matches_subdomains =
>
> smtpd_sender_restrictions =
> check_sender_access inline:{
> { example.com = DISCARD blackholed sender domain },
> { .example.com = DISCARD blackholed sender domain },
> }
>
> On Sat, Apr 22, 2023 at 08:09:59PM -0700, Andrew Athan wrote:
> >
> > Oh, sorry, one last (lol) thing ... since it doesn't seem like "@" is
> ever
> > part of searches
>
> This is a false premise, so the rest is moot. See the documented lookup
> keys for each table-driven feature.
>
> --
> 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
