On Thu, Feb 18, 2021 at 02:00:11PM +0100, Ralph Seichter wrote:
> > I strongly do not recommend using LDAP for per-user transport lookups.
>
> Shame that it does not scale, because it works. I have tried using a
> combination of LDAP-based virtual_alias_maps and hashed transport_maps
> as per your suggestion, but have not yet quite achieve the result I am
> looking for.
>
> Let me modify the pseudocode to describe my goal in more detail:
>
> x = ldap_lookup_recipient_record(envelope_to_address)
> if x.has_attribute(alpha)
> reject_with_code_4xx(message=value_of_attribute(alpha))
> else
> relay_message(nexthop=value_of_attribute(beta))
You should not be using the transport(5) table for SMTP access control,
that's what access(5) is for. LDAP used in access(5) tables works just
fine. And scales better because while there's only one queue-manager,
there are many smtpd(8) processes, whose LDAP queries are concurrent,
(typically via multiple instances of proxymap, which scales up on
demand).
> When I use transport lookups, this is possible, for example by setting
> attributes alpha="retry:Unavailable" or beta="smtp:[somehost]".
The mistake is using transport(5) for access control.
> I tried to emulate this by using virtual alias lookups which return
> alpha="pause.domain.tld" or beta="route.domain.tld", combined with a
> transports hash map containing
>
> pause.domain.tld retry:Unavailable
> route.domain.tld smtp:[somehost]
Sorry, that was for actually delivering email, not for simulating
access control (square peg, round hole).
--
Viktor.
