[LDAP] Postfix-style virtual domain!
Meder Bakirov
There is little thing, I'm confused about and which should solve my all other
problems, I hope! ;)
I want to use Postfix-style virtual domains and, as you know, it has a syntax
like this [/etc/postfix/virtual]:
virtual.domain anything
us...@virtual.domain us...@another.domain
us...@virtual2.domain us...@another2.domain
All I want to do is to lookup these entries in LDAP tree. I will have
virtual_maps defined for global aliases:
virtual_maps = ldap:aliases
aliases_server_host = localhost
aliases_search_base = dc=mydomain,dc=com
aliases_query_filter = (&(objectClass=Alias)(mail=%s))
aliases_result_attribute = maildrop
aliases_bind = no
And an entry, like:
...
objectclass: Alias
mail: us...@virtual.domain
maildrop: us...@another.domain
...
And a thing, that confuse me is the first line of a Postfix-style virtual
domain syntax [/etc/postfix/virtual]:
virtual.domain anything
...
Should I define this line in LDAP or I can bypass it? If I should include this
line, how can I define this in LDAP? Like this:
...
objectclass: Alias
mail: virtual.domain
maildrop: anything
...
?
And what is the queue of this line to be looked up? - Will it be looked up
firstly, then other lines?
The case is that, I don't want a local user (e.g. test) to recieve a mail for
te...@virtual.domain, when there is no user "test" in virtual.domain!
Any other solutions and suggestions are welcome!
Please, help me and let me die happy ;) The only (that I know) confusion, I
have for the moment!
--
Rgrds, .coder!
PS. BTW, I'm sorry, if my question disturbed you and if it is stupid!
-
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users
Greg Crosby
tree with each domain as an entry with the correct attributes the user entry
is then below this entry in the tree
eg
dn:cn=domain.com, ou=domains, dc=isp,dc=net
mail: domain.com
maildrop: whatever
and user then has a dn of
dn: cn=us...@domain.com,cn=domain.com,ou=domain,dc=isp,dc=net
postfix will always lookup the domain first and then the user so therefore
if the domain doesn't exist in the directory the mail will be
bounced/rejected
but if the domain entry does exist then postfix will do a lookup for the
us...@domain.com and if that doesn't exist then the mail will be
bounced/rejected
so te...@domain.com will not be accepted if there is no ldap entry for test
Greg Crosby
Pre-Sales Consultant
Netkonect Communications plc
Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
Meder Bakirov
dc=net
|
dc=isp
|
ou=domains
| |
cn=domain.com cn=example.com
|
cn=us...@domain.com
, isn't it?
Does dn:cn=domain.com, ou=domains, dc=isp,dc=net contain these attributes:
mail and maildrop, where mail=domain.com and maildrop=anything? So, how do
you perform a lookup? - Can you provide me, please, a sample of a lookup, you
perform? How to let Postfix know, it is a Postfix-style virtual domain?
Thank you very much!
On Thursday 5 September 2002 16:06, you wrote:
> Yes you still need the domain line we have a ou=domain layer in our ldap
> tree with each domain as an entry with the correct attributes the user
> entry is then below this entry in the tree
> eg
> dn:cn=domain.com, ou=domains, dc=isp,dc=net
>
> mail: domain.com
> maildrop: whatever
>
> and user then has a dn of
>
> dn: cn=us...@domain.com,cn=domain.com,ou=domain,dc=isp,dc=net
>
> postfix will always lookup the domain first and then the user so therefore
> if the domain doesn't exist in the directory the mail will be
> bounced/rejected
>
> but if the domain entry does exist then postfix will do a lookup for the
> us...@domain.com and if that doesn't exist then the mail will be
> bounced/rejected
>
> so te...@domain.com will not be accepted if there is no ldap entry for test
>
>
>
> Greg Crosby
> Pre-Sales Consultant
> Netkonect Communications plc
> Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
--
Rgrds, .coder!
Greg Crosby
Greg Crosby
Pre-Sales Consultant
Netkonect Communications plc
Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
>So, LDAP tree, you have is
>dc=net
> |
>dc=isp
> |
> ou=domains
> | |
> cn=domain.com cn=example.com
>|
>cn=us...@domain.com
>, isn't it?
yes
>Does dn:cn=domain.com, ou=domains, dc=isp,dc=net contain these attributes:
>mail and maildrop, where mail=domain.com and maildrop=anything?
yes
>So, how do
>you perform a lookup? - Can you provide me, please, a sample of a lookup,
you
>perform?
postfix will do the lookup for the domain just as it does for the users
>How to let Postfix know, it is a Postfix-style virtual domain?
postfix will know because it will find the domain when it does a virtual
lookup on your ldap and finds the domain entry is present
Russell Mosemann
> And a thing, that confuse me is the first line of a Postfix-style virtual
> domain syntax [/etc/postfix/virtual]:
>
> virtual.domain anything
> ...
>
> Should I define this line in LDAP or I can bypass it?
Yes. It is required as a "marker" for that domain, and the domain may not
appear anywhere else (e.g., not in mydestination, relay_maps or any other
place). If the marker doesn't exist, it is not seen as a virtual domain.
virtual_maps then acts like a global alias file. The only exception to
the marker rule is that the marker must appear in virtual_mailbox_maps
instead of virtual_maps, if you use virtual_mailbox_maps.
> If I should include this
> line, how can I define this in LDAP? Like this:
> ...
> objectclass: Alias
> mail: virtual.domain
> maildrop: anything
Sure. That would be fine. Anything, of course, can be anything.
> And what is the queue of this line to be looked up? - Will it be looked up
> firstly, then other lines?
It is looked up when mail is received to see if the computer is a
destination for that domain. If the domain is found, then other lookups
are done to find the user's address. If the user's address is not found,
then the message is rejected with "Unknown user".
> The case is that, I don't want a local user (e.g. test) to recieve a mail for
> te...@virtual.domain, when there is no user "test" in virtual.domain!
That won't happen, because you are using a postfix-style virtual domain,
and all known users in that domain will be listed in virtual_maps. If you
used a sendmail-style virtual domain, then you'd have the problem you're
talking about.
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"What's the difference between ignorance and apathy?
I don't know and I don't care."
Meder Bakirov
I have these LDAP sources:
To automatically lookup a new domain, I have defined transport_maps as
follows:
------------------------------------------------
transport_maps = ldap:trasnport
transport_server_host = localhost
transport_search_base = o=hosting,dc=myhosting,dc=example
transport_query_filter = (&(jvd=%s)(objectClass=JammVirtualDomain))
transport_result_attribute = postfixTransport
transport_cache = yes
transport_bind = no
transport_scope = one
, which will always return virtual
for aliases, I use virtual_maps:
------------------------------------------------
virtual_maps = ldap:aliases
aliases_server_host = localhost
aliases_search_base = o=hosting,dc=myhosting,dc=example
aliases_query_filter =
(&(&(objectClass=JammMailAlias)(mail=%s))(accountActive=TRUE))
aliases_result_attribute = maildrop
aliases_bind = no
aliases_cache = yes
for accounts, I use virtual_mailbox_maps:
------------------------------------------------
virtual_mailbox_base = /home/vmail/domains
virtual_mailbox_maps = ldap:accounts
virtual_minimum_uid = 101
virtual_uid_maps = static:101
virtual_gid_maps = static:101
accounts_server_host = localhost
accounts_search_base = o=hosting,dc=myhosting,dc=example
accounts_query_filter =
(&(&(objectClass=JammMailAccount)(mail=%s))(accountActive=TRUE))
accounts_result_attribute = mailbox
accounts_cache = yes
accounts_bind = no
Ane each entry has a format:
transport
-----------
...
objectclass: JammVirtualDomain
jvd: virtual.com
postfixTransport: virtual
...
alias
-----
...
objectclass: JammMailAlias
mail: us...@virtual.com
maildrop: us...@another.com
accountActive: TRUE
...
account
---------
...
objectclass: JammMailAccount
mail: us...@another.com
mailbox: another.com/user/
accountActive: TRUE
...
So, AFAIK, Postfix first makes a lookup in virtual_maps, then in
transport_maps, and only then in virtual_mailbox_maps. Am I right?
Where and how would I define Postfix-style virtual domain in given samples?
Please provide me, if you can, a sample entry!
--
Rgrds, .coder!
Russell Mosemann
> To automatically lookup a new domain, I have defined transport_maps as
> follows: transport_maps = ldap:trasnport
...
> , which will always return virtual
You only need to define transport_maps if delivery will be done using a
different transport than the default transport. The transport for local
accounts is local. The transport for virtual mailboxes is virtual. You
don't have to explicitly say it. However, if you wanted to use something
like maildrop for the virtual transport, then you would have define
that. Besides, if a lookup will always return the same value, don't waste
time on a lookup. Put it in a file or at least make it a static: entry.
> for aliases, I use virtual_maps:
OK.
> for accounts, I use virtual_mailbox_maps:
OK.
> So, AFAIK, Postfix first makes a lookup in virtual_maps, then in
> transport_maps, and only then in virtual_mailbox_maps. Am I right?
No. It's best to assume that Postfix will do whatever lookup it needs to
do whenever it wants to do it.
> Where and how would I define Postfix-style virtual domain in given samples?
> Please provide me, if you can, a sample entry!
Since you are using virtual_mailbox_maps, you must put a virtual domain
marker ("domain anything") in virtual_mailbox_maps. It must not occur
anywhere else. This topic has been discussed in painful detail over and
over. Search this list for more information using the words "ldap
virtual" and "virtual domain".
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"We deliver anywhere in the world in 30 minutes or less, or the
next one's free." - Nuclear missle silo commander
Victor....@morganstanley.com
> On Fri, 6 Sep 2002, Meder Bakirov wrote:
>
> > To automatically lookup a new domain, I have defined transport_maps as
> > follows: transport_maps = ldap:trasnport
> ...
> > , which will always return virtual
>
> You only need to define transport_maps if delivery will be done using a
> different transport than the default transport. The transport for local
> accounts is local. The transport for virtual mailboxes is virtual. You
> don't have to explicitly say it. However, if you wanted to use something
> like maildrop for the virtual transport, then you would have define
> that. Besides, if a lookup will always return the same value, don't waste
> time on a lookup. Put it in a file or at least make it a static: entry.
>
This is misleading, the default transport for domains that don't match
$mydestination is "smtp". Postfix does not yet have a default "virtual"
transport. One can however map the entire domain (via a file based map) to
the "virtual" transport with a single user entry and avoid per user
transport lookups in LDAP. Using LDAP for transport lookups has
substantial drawbacks...
>
> > So, AFAIK, Postfix first makes a lookup in virtual_maps, then in
> > transport_maps, and only then in virtual_mailbox_maps. Am I right?
>
> No. It's best to assume that Postfix will do whatever lookup it needs to
> do whenever it wants to do it.
>
No. It is best to understand (at least at a high level) the sequence in which
address rewrites and lookups occur.
- smtpd does recipient *validation*. The input address is
first resolved via the trivial-rewrite service which performs
transport table lookups. Then canonica, virtual,
virtual_mailbox_maps, relocated_maps, local_recipient_maps, ...
are checked for evidence of mailbox validity as appropriate.
- cleanup does address rewriting (canonical_maps, masquerading,
virtual_maps). The addresses are resolved via trivial-rewrite with
yet another set of transport_table lookups.
- qmgr does "relocated" processing and bounces recipients in
Postfix-style virtual domains (so non-local domains are looked up
in $virtual_maps in search of the magic "anything" entries). Again
transport table lookups (don't use LDAP for this unless you
have a gun pointed at your head...)
- delivery agents consult whatever tables they want. "local" looks
at alias_maps and mailbox_command_maps. "virtual" looks at
"virtual_mailbox_maps", ... "maildrop" looks at "userdb" ...
It is important to know for example the virtual_maps (even catchall
entries) takes precedence over virtual_mailbox_maps (even specific user
data) because cleanup only looks at virtual_maps and gets the message
before the delivery agent does.
> > Where and how would I define Postfix-style virtual domain in given samples?
> > Please provide me, if you can, a sample entry!
>
> Since you are using virtual_mailbox_maps, you must put a virtual domain
> marker ("domain anything") in virtual_mailbox_maps. It must not occur
> anywhere else. This topic has been discussed in painful detail over and
> over. Search this list for more information using the words "ldap
> virtual" and "virtual domain".
>
I call this a virtual mailbox domain, with Postfix-style virtual domains
reserved for domains in $virtual_maps. There is not yet in this space a
standard nomenclature blessed by Wietse AFAIK.
--
Viktor.
Meder Bakirov
> On Fri, 6 Sep 2002, Meder Bakirov wrote:
> > To automatically lookup a new domain, I have defined transport_maps as
> > follows: transport_maps = ldap:trasnport
>
> ...
>
> > , which will always return virtual
>
> You only need to define transport_maps if delivery will be done using a
> different transport than the default transport. The transport for local
> accounts is local. The transport for virtual mailboxes is virtual. You
> don't have to explicitly say it. However, if you wanted to use something
> like maildrop for the virtual transport, then you would have define
> that. Besides, if a lookup will always return the same value, don't waste
> time on a lookup. Put it in a file or at least make it a static: entry.
I need this to automatically lookup a new added virtual domain!
>
> > for aliases, I use virtual_maps:
>
> OK.
>
> > for accounts, I use virtual_mailbox_maps:
>
> OK.
>
> > So, AFAIK, Postfix first makes a lookup in virtual_maps, then in
> > transport_maps, and only then in virtual_mailbox_maps. Am I right?
>
> No. It's best to assume that Postfix will do whatever lookup it needs to
> do whenever it wants to do it.
Can you explain me a step-by-step procedure: message comes in, and what's then
- virtual_maps, transport, virtual_mailbox_maps?
>
> > Where and how would I define Postfix-style virtual domain in given
> > samples? Please provide me, if you can, a sample entry!
>
> Since you are using virtual_mailbox_maps, you must put a virtual domain
> marker ("domain anything") in virtual_mailbox_maps. It must not occur
> anywhere else. This topic has been discussed in painful detail over and
> over. Search this list for more information using the words "ldap
> virtual" and "virtual domain".
So, should it be like this?
virtual_mailbox_maps = ldap:accounts
...
objectclass: JammMailAccount
mail: virtual.domain
mailbox: anything
accountActive: TRUE
...
But then, why this line (virtual.domain anything) is defined in virtual
(/etc/postfix/virtual/) file (,which is virtual_maps)?
Why not virtual_maps? Like this:
virtual_maps = ldap:aliases
...
objectclass: JammMailAlias
mail: virtual.domain
maildrop: anything
accountActive: TRUE
...
? Too confusing to me now :) - I think, I won't die happily :)
>
> ----
> Russell Mosemann, Ph.D. * Computing Services * Concordia University,
> Nebraska "We deliver anywhere in the world in 30 minutes or less, or the
> next one's free." - Nuclear missle silo commander
--
Rgrds, .coder!
Russell Mosemann
> > > follows: transport_maps = ldap:trasnport
>
> I need this to automatically lookup a new added virtual domain!
I guess I don't see how that's related to the transport you want to use.
> So, should it be like this?
>
> virtual_mailbox_maps = ldap:accounts
> ...
> objectclass: JammMailAccount
> mail: virtual.domain
> mailbox: anything
> accountActive: TRUE
Yes.
> But then, why this line (virtual.domain anything) is defined in virtual
> (/etc/postfix/virtual/) file (,which is virtual_maps)?
The virtual domain should NOT be defined in both virtual_maps and
virtual_mailbox_maps. Using Victor's terminology, a domain is either a
virtual domain or it is a virtual mailbox domain, but it can't be both.
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"Semper Ubi Sub Ubi"
Russell Mosemann
> I call this a virtual mailbox domain, with Postfix-style virtual domains
> reserved for domains in $virtual_maps. There is not yet in this space a
> standard nomenclature blessed by Wietse AFAIK.
Doesn't the domain entry in virtual_mailbox_maps perform the same job as
the domain entry in virtual_maps, that is, to confirm that it is a
virtual domain and the local computer is a final destination for it?
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"If you've seen one shopping center, you've seen a mall!"
Victor....@morganstanley.com
> On Thu, 5 Sep 2002 Victor....@morganstanley.com wrote:
>
> > I call this a virtual mailbox domain, with Postfix-style virtual domains
> > reserved for domains in $virtual_maps. There is not yet in this space a
> > standard nomenclature blessed by Wietse AFAIK.
>
> Doesn't the domain entry in virtual_mailbox_maps perform the same job as
> the domain entry in virtual_maps, that is, to confirm that it is a
> virtual domain and the local computer is a final destination for it?
>
Yes. The difference is that virtual mailbox domains host deliverable
mailboxes (via a suitable VDA), while Postfix-style virtual domains host
only "redirects" (my term) to other domains (possibly via recursive
indirection).
The virtual mailbox domains support recipient validation just like
Postfix-style virtual domains. One can use a VDA to deliver mail to a
"relay_domain" and lose this validation, this is usually not a good
idea.
So virtual mailbox domains (with domain anything keys in
$virtual_mailbox_maps) are not Postfix-style virtual domains. Both are
final, but the first is deliverable as is (with a suitable virtual email
user database provided to the VDA) while the second is not deliverable
unless rewritten.
--
Viktor.
ktsuresh
domains
> > > reserved for domains in $virtual_maps. There is not yet in this space
a
> > > standard nomenclature blessed by Wietse AFAIK.
> >
It is really confusing infact.
> > Doesn't the domain entry in virtual_mailbox_maps perform the same job as
> > the domain entry in virtual_maps, that is, to confirm that it is a
> > virtual domain and the local computer is a final destination for it?
> >
>
> Yes. The difference is that virtual mailbox domains host deliverable
> mailboxes (via a suitable VDA), while Postfix-style virtual domains host
> only "redirects" (my term) to other domains (possibly via recursive
> indirection).
Some entries in the virtual_mailbox_maps looks like
virtual.domain anything
and the other entries for the virtual users looks entirely different (which
includes their Maildirectories etc) creats confusion.
>
> The virtual mailbox domains support recipient validation just like
> Postfix-style virtual domains. One can use a VDA to deliver mail to a
> "relay_domain" and lose this validation, this is usually not a good
> idea.
>
> So virtual mailbox domains (with domain anything keys in
> $virtual_mailbox_maps) are not Postfix-style virtual domains. Both are
> final, but the first is deliverable as is (with a suitable virtual email
> user database provided to the VDA) while the second is not deliverable
> unless rewritten.
what does this mean exactly.
Keith T. Garner
[snip]
> This is misleading, the default transport for domains that don't match
> $mydestination is "smtp". Postfix does not yet have a default "virtual"
> transport. One can however map the entire domain (via a file based map) to
> the "virtual" transport with a single user entry and avoid per user
> transport lookups in LDAP. Using LDAP for transport lookups has
> substantial drawbacks...
> - qmgr does "relocated" processing and bounces recipients in
> Postfix-style virtual domains (so non-local domains are looked
> up in $virtual_maps in search of the magic "anything"
> entries). Again transport table lookups (don't use LDAP for
> this unless you have a gun pointed at your head...)
I've seen assertions like this before (against using LDAP in this
manner) on this list, would anyone care to explain why? I'm currently
at a loss, except, perhaps, performance issues....
Keith
--
Keith T. Garner kga...@kgarner.com
The whole problem with the world is that fools and fanatics are always so
certain of themselves, and wiser people so full of doubts. --Bertrand Russell
Victor....@morganstanley.com
> > entries). Again transport table lookups (don't use LDAP for
> > this unless you have a gun pointed at your head...)
>
> I've seen assertions like this before (against using LDAP in this
> manner) on this list, would anyone care to explain why? I'm currently
> at a loss, except, perhaps, performance issues....
>
Performance and reliability. The trivial-rewrite daemon is single-threaded
(event driven non-blocking for Postfix IPC, but not map lookups). It is
consulted by the "smtpd", "cleanup", "qmgr" and "local". This sends a lot
of queries to LDAP via a single LDAP connection that can do only one query
at a time. The performance consequences can be severe for high volume
sites.
LDAP is also prone to more failure modes than access to local disk files.
Finally LDAP libraries (and even some older versions of dict_ldap.c in
Postfix combined with LDAP version 2 API) can have memory leaks. As both
"trivial-rewrite" and "qmgr" run forever, the leaks can degrade
performance and eventually consume all system memory.
Transport table lookups should have a predictable low latency and high
availability. I don't believe that LDAP qualifies.
--
Viktor.
Russell Mosemann
> Transport table lookups should have a predictable low latency and high
> availability. I don't believe that LDAP qualifies.
But as long as you are able to throw faster disks, more memory and faster
CPUs at the problem to stay ahead of email processing, you should be OK.
:-)
We use files for transport lookup, but we use LDAP for other maps. The
thing I like about it is that LDAP is distributed. When a change is made,
it goes to all of the replicants immediately and is available for a table
lookup right away. If one of the LDAP servers goes down for maintenance
or whatever, postfix uses the next one (if multiple LDAP servers are
specified). We don't have near the email volume that other people on this
list are mentioning. So, the performance is more than adequate for us.
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"A prudent man sees danger and takes refuge, but the simple keep
going and suffer for it." - Prov. 22:3
Victor....@morganstanley.com
> On Fri, 6 Sep 2002 Victor....@morganstanley.com wrote:
>
> > Transport table lookups should have a predictable low latency and high
> > availability. I don't believe that LDAP qualifies.
>
> But as long as you are able to throw faster disks, more memory and faster
> CPUs at the problem to stay ahead of email processing, you should be OK.
> :-)
>
Actually since each recipient is looked up in LDAP a few times per
delivery (at least three via "smtpd", "cleanup" and "qmgr", but I suspect
that "cleanup" does multiple lookups) and the LDAP lookups are serialized,
the mail throughput in messages per second is bounded by 1/N*LDAP_latency
wehre N is the number of lookups per recipient and LDAP_latency query
latency measured in seconds. If the LDAP lookup latency is 10ms and N=5
one gets at most 20 messages per second. This bound is too low for many
sites, one needs a fast LDAP server on a low latency (100MB/s end to
end) low hop count link.
I know it can be made to work, but I don't recommend it. In the
nebulous future when pigs learn to fly perhaps transport lookups will be
performed concurrently by multiple processes which have a finite
lifetime and the recommendation will change. There will still be a pitfall
unless ldapsource_bind = no, because when the primary server fails
throughput will be limited to $max_use messages per N*$ldapsource_timeout
seconds (where N is the larger of the number of LDAP connections made by
"smtpd" or "cleanup"). Tuning LDAP for high volume can be tricky for
non-experts.
TODO items:
- Make ldapsource_bind = no by default.
- Implement connection sharing for ldap maps when two maps
with bind = no have the same (server, port) parameters.
This exists in Sendmail 8.11.4 and later (broken in 8.11.3)
with sharing also enabled for maps that bind with same dn and
password, but I think this is overkill. If you want performance
don't bind.
--
Viktor.
Greg Crosby
>in your own organization), and I don't think the path to a virtual mailbox
>is going to be all that useful to most people.
except spammers who would love to get the 20,000 valid email addresses on
our mail server
Greg Crosby
Pre-Sales Consultant
Netkonect Communications plc
Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
Christian Kratzer
On Mon, 9 Sep 2002, Greg Crosby wrote:
> >I'd hardly consider an email address to be private information (at least
> >in your own organization), and I don't think the path to a virtual mailbox
> >is going to be all that useful to most people.
>
> except spammers who would love to get the 20,000 valid email addresses on
> our mail server
I would not allow external whitepages style access to my ldap server.
Use tcp_wrappers or other firewalling techniques to allow ldap access
to your postfix servers and your internal clients only.
Of course the perfect solution would be to have an external long lived
map lookup process that could bind once as postfix. But we are not
there yet.
Greetings
Christian
--
CK Software GmbH
Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen
Email: c...@cksoft.de
Phone: +49 7452 889-135 Open Software Solutions, Network Security
Fax: +49 7452 889-136 FreeBSD spoken here!
Victor....@morganstanley.com
> Of course the perfect solution would be to have an external long lived
> map lookup process that could bind once as postfix. But we are not
> there yet.
>
This eliminates opportunities for concurrency. Serializing all LDAP
lookups is not a good idea. The LDAP server is multi-threaded, so having
multiple processes accessing it can ammortize the per query latency.
A multi-threaded external LDAP front-end would not be a good idea IMHO, so
it would need to be a pre-forking process like the current cleanup. Fewer
processes may suffice, because the query response cycle is short, so one
map lookup daemon could "concurrently" (actually time-sliced) serve
multiple "smtpd" processes. The "max_use" for this process should be set
high due to the high query rate and low query latency. It should not be
long lived (i.e. a finite positive max_use to avoid memory leak problems).
So the bottom line is whether there a win from moving all map lookups into
co-processes. It is not clear this is a win...
One could also have multiple LDAP sessions within the same process, and
use non-blocking LDAP calls. This is very complex.
--
Viktor.
Victor....@morganstanley.com
> > > surely you would not want anyone to be able to browse your directories
> with
> > > anonymous access?
> > >
> >
> > Your LDAP host/port should not be reachable from the Internet. Passwords
> > are not the right mechanism to restrict access to your LDAP server.
>
> it is not the only method but surely still essential if only as a last line
> of defence should any of the servers behind the firewall be compromised
>
> security is all about layers, the more the better so my original point that
> you should not use anonymous binds to gather sensitive data across a network
> still stands
>
Put your LDAP servers in private address space, so no routes exist to them
from the Internet. If you insist on paying the performance degradation of
LDAP bind, set max_use to 1000 from the default 100, otherwise your
throughput will suffer significantly when the primary LDAP server is down.
I don't have time to explain why, sorry :-( Figuring out why is a hard but
fun problem...
Greg Crosby
with
> > anonymous access?
> >
>
> Your LDAP host/port should not be reachable from the Internet. Passwords
> are not the right mechanism to restrict access to your LDAP server.
it is not the only method but surely still essential if only as a last line
of defence should any of the servers behind the firewall be compromised
security is all about layers, the more the better so my original point that
you should not use anonymous binds to gather sensitive data across a network
still stands
Greg Crosby
Pre-Sales Consultant
Netkonect Communications plc
Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
Russell Mosemann
> How do you specify multiple replicated ldapservers for postfix? I wanted
> to do that but could not find any documentation.
It is described in LDAP_README under the explanation for "server_host".
ldapwhatever_server_host = ldap1.example.com ldap2.example.com ldap3.example.com
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"He was inebriated with the exuberance of his own verbosity."
Greg Crosby
>
> Put your LDAP servers in private address space, so no routes exist to them
> from the Internet. If you insist on paying the performance degradation of
> LDAP bind, set max_use to 1000 from the default 100, otherwise your
> throughput will suffer significantly when the primary LDAP server is down.
> I don't have time to explain why, sorry :-( Figuring out why is a hard but
> fun problem...
>
if your mail server is hosted in a well connected hosting centre and
connected to huge bandwidth then hiding the ldap server from it on
non-routable addresses is not going to do the job although you are right
that it would keep it safe ;)
as to the max_use function I had not heard of that , is it mentioned in any
documentation anywhere?
Greg Crosby
Pre-Sales Consultant
Netkonect Communications plc
Opus House, Manor Court, Herriard, Basingstoke, RG25 2PH
-
Victor....@morganstanley.com
> as to the max_use function I had not heard of that , is it mentioned in any
> documentation anywhere?
>
No this is not documented, I learned it the hard way :-(
Basically when
ldap_server_host = ldap1 ldap2 ...
ldap_timeout = N
ldap_bind = yes
if "ldap1" is down (connections time out, not refused), throughput is
limited to max_use messages per k*N seconds (where k is the number of LDAP
maps). With max_use = 100 (default) and the ldap timeout = 10s (default)
you can deliver at most 10 messages per second (5 if cleanup uses 2 LDAP
maps, ...)
With ldap_bind = no, the throughput is multiplied by the cleanup process
limit and is generally high enough that other resources are exhausted
first.
--
Viktor.
Christian Kratzer
On Mon, 9 Sep 2002 Victor....@morganstanley.com wrote:
> On Mon, 9 Sep 2002, Christian Kratzer wrote:
>
> > Of course the perfect solution would be to have an external long lived
> > map lookup process that could bind once as postfix. But we are not
> > there yet.
> >
>
> This eliminates opportunities for concurrency. Serializing all LDAP
> lookups is not a good idea. The LDAP server is multi-threaded, so having
> multiple processes accessing it can ammortize the per query latency.
good point
> A multi-threaded external LDAP front-end would not be a good idea IMHO, so
> it would need to be a pre-forking process like the current cleanup. Fewer
> processes may suffice, because the query response cycle is short, so one
> map lookup daemon could "concurrently" (actually time-sliced) serve
> multiple "smtpd" processes. The "max_use" for this process should be set
> high due to the high query rate and low query latency. It should not be
> long lived (i.e. a finite positive max_use to avoid memory leak problems).
>
> So the bottom line is whether there a win from moving all map lookups into
> co-processes. It is not clear this is a win...
and would propably introduce more complexity than we care for.
> One could also have multiple LDAP sessions within the same process, and
> use non-blocking LDAP calls. This is very complex.
perhaps some kind of caching mechanism would be good. Client side
caching in openldap seems to be broken currently as we all know.
No need to duplicate this behaviour in postfix assuming the caching
gets fixed sometime.
Greetings
Christian
--
CK Software GmbH
Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen
Email: c...@cksoft.de
Phone: +49 7452 889-135 Open Software Solutions, Network Security
Fax: +49 7452 889-136 FreeBSD spoken here!
Russell Mosemann
> Client side
> caching in openldap seems to be broken currently as we all know.
> No need to duplicate this behaviour in postfix assuming the caching
> gets fixed sometime.
This was true for ealier versions, but OpenLDAP is up to 2.1.4. Has
anyone tested it recently?
----
Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"Arp! Arp!" - the mating call of the lonely packet
Victor....@morganstanley.com
> On Mon, 9 Sep 2002, Christian Kratzer wrote:
>
> > Client side
> > caching in openldap seems to be broken currently as we all know.
> > No need to duplicate this behaviour in postfix assuming the caching
> > gets fixed sometime.
>
> This was true for ealier versions, but OpenLDAP is up to 2.1.4. Has
> anyone tested it recently?
>
Equally important is whether anyone has read the code recently. The
original caching code was not only broken, but also poorly designed.
--
Viktor.