From: Phil Howard (no email)
Date: Tue Jul 02 2002 - 10:49:08 EDT
On Tue, Jul 02, 2002 at 09:20:44AM -0400, wrote:
| On Tue, 2 Jul 2002, Phil Howard wrote:
|
| > Just search ONE map, the one for the appropriate domain. Then we're
| > doing 1*ln(n/x) ... times whatever it takes for the filesystem to
| > find that map ... which makes it ln(n/x)+ln(x) ... or ln(max(n/x,x))
| > as far as big-O is concerned.
| >
|
| To avoid running out of file descriptors this would need to be implemented
| as a new (to Postfix) hierarchical map type. It will complicate chroot
| setup, because the map hierarchy would need to be loopback (bind) mounted
| into the chroot jain (always the Postfix queue directory). Additionally
| the submaps for each domain would need to opened and closed on the fly,
| with a suitable cache of open maps to avoid opening and closing maps for
| every lookup. The underlying per domain map would need to be "cdb", not
| Berkeleyu DB, since allocating and deallocating page pools and other map
| open overhead in Berkeley DB potentially impacts lookup performance in a
| negative way). What is the relative cost of map open vs. key lookup with
| "cdb"?
My understanding is that DJBDNS opens cdb for every request.
| Postfix maps do not know whether the lookup key is a user name, address,
| domain name, ..., this happens at a higher layer accross all the map
| types. Postfix maps just look up strings. Your map needs to parse its
| keys into a domain and a user part. This conflicts with the Postfix
| keyed map abstraction. Like "regexp" maps your map might need to avoid
| "partial" keys so as not to get confused by source routes. There may be
| other semantic subleties.
I might create a map type that simply constructs strings from keys. Maybe
the regexp map can already do what I need.
| Actually LDAP maps with ldapsource_domain set also violate the abstraction
| when filtering the input keys by domain, perhaps such maps should also
| avoid "partial" keys.
|
| Your proposal is a non-trivial development effort. Are you sure that your
| energy and enthusiasm will be best spent in this direction? It would be
| much easier to deploy something existing of the shelf even if slightly
| imperfect the solutions will have been tested by others and known to work.
|
| Of course all real progress is made by people who are wisely or otherwise
| unhappy with the status quo, I do not want to discourage creativity, just
| be aware that innovation is a risky business... :-(
Another option on the table being explored is developing my own SMTP daemon.
But this would be a very specialized one, not for general use. For example
it would not do any relaying whatsoever, so if you want to be able to inject
mail and have it delivered on the internet, or run an MX other than the final
destination, run another MTA, e.g. Postfix. It could also do LMTP. It would
only do maildir so that it wouldn't face having to otherwise queue mail, so
it would be a deliver-during-receipt type daemon, too. Its primitiveness
and lack of intent to support various other sendmail-ish things means it
would be a smaller project, and potentially viable. I'm not sure if would
go this route, but it's still an option. I have ruled out other MTAs for
the most part.
-- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|