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
