In a new server setup, I use two consecutive transport lookups:
transport_maps = ldap:/etc/postfix/foo.cf ldap:/etc/postfix/bar.cf
The lookup defined in foo.cf MAY return a result for a given recipient,
while using bar.cf MUST return a result. This works, but with a caveat:
Adding or removing t
On Thu, Feb 18, 2021 at 07:52:07AM +0100, Ralph Seichter wrote:
> In a new server setup, I use two consecutive transport lookups:
>
> transport_maps = ldap:/etc/postfix/foo.cf ldap:/etc/postfix/bar.cf
I strongly do not recommend using LDAP for per-user transport lookups.
Instead:
- Use vi
* Viktor Dukhovni:
> 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
A Postfix process won't look up transport_maps if the same query
repeats, but when I look at the code, there is a 30-second time
limit on the reusing the cached response. Is that not sufficient?
Wietse
* Wietse Venema:
> A Postfix process won't look up transport_maps if the same query
> repeats, but when I look at the code, there is a 30-second time
> limit on the reusing the cached response. Is that not sufficient?
Maybe it would help if I described the scenario in more detail. Consider
an LDA
Wietse Venema:
> A Postfix process won't look up transport_maps if the same query
> repeats, but when I look at the code, there is a 30-second time
> limit on the reusing the cached response. Is that not sufficient?
Sorry, that is the resolve client cache, not the transport_map
cache. But the res
Ralph Seichter:
> In order to keep the window for temporary message rejection as small as
> possible, the LDAP attribute is set immediately before maintenance
> starts, and is removed immediately after maintenance ends. Any caching
> interferes when incoming traffic volume is high, even 30 seconds
Wietse Venema:
> Ralph Seichter:
> > In order to keep the window for temporary message rejection as small as
> > possible, the LDAP attribute is set immediately before maintenance
> > starts, and is removed immediately after maintenance ends. Any caching
> > interferes when incoming traffic volume
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 you
On Thu, Feb 18, 2021 at 10:56:24AM -0500, Viktor Dukhovni wrote:
> > 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))
>
Viktor Dukhovni:
> Bottom line, use the transport(5) table for routing, and access(5) for
> access control.
These are queried at different points in time. Is this race-condition
safe, i.e. can LDAP reponses change while an email message is in
flight inside Postfix?
Wietse
* Wietse Venema:
> Actually, drain caches and queues BEFORE updating LDAP, so that
> LDAP is not changing while Postfix is still processing email.
The maintenance service and Postfix only intersect in LDAP, and moving
an account between servers can happen at any time. That's why I can only
rely o
On Thu, Feb 18, 2021 at 11:53:56AM -0500, Wietse Venema wrote:
> Viktor Dukhovni:
> > Bottom line, use the transport(5) table for routing, and access(5) for
> > access control.
>
> These are queried at different points in time. Is this race-condition
> safe, i.e. can LDAP reponses change while an
13 matches
Mail list logo
