check_mx_access, was Re: wishlist
Ralf Hildebrandt
> > 2) since there seems to be a growing number of sites with MX = 127.0.0.1 would
> > an smtpd_sender_restriction like "reject_mx_localhost" be considered useful? The
> > action would be to reject any domain where the MX = 127.0.0.1. It'd be easier
> > than trying to keep adding them to blacklists.
>
> That would have to be something like reject_mx_maps, where the MX
> record returned is being resolved and then a map lookup is made.
> Example:
>
> reject_mx_maps_access hash:/etc/postfix/forbidden_mx_networks
check_mx_access would be a better name.
> /etc/postfix/forbidden_mx_networks:
>
> 10 REJECT You silly person
> 127 REJECT Keep you crap
>
> --
> Ralf Hildebrandt Ralf.Hil...@charite.de
> my current spamtrap partmap...@charite.de
> http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
> Why you can't find your system administrators:
> (S)he's joined a cult practising Windoze 95
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
"How would you rate our government's incompetence?
Typical unix response: Unmatched ".
Victor....@morganstanley.com
> > > 2) since there seems to be a growing number of sites with MX = 127.0.0.1 would
> > > an smtpd_sender_restriction like "reject_mx_localhost" be considered useful? The
> > > action would be to reject any domain where the MX = 127.0.0.1. It'd be easier
> > > than trying to keep adding them to blacklists.
> >
> > That would have to be something like reject_mx_maps, where the MX
> > record returned is being resolved and then a map lookup is made.
> > Example:
> >
> > reject_mx_maps_access hash:/etc/postfix/forbidden_mx_networks
>
> check_mx_access would be a better name.
>
If the map is unlikely to ever contain an OK entry, a namaddr matchlist
*may* be more appropriate than a map. This would also support CIDR
notation.
bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
smtpd_sender_restrictions =
permit_mynetworks,
reject_bad_sender_mx,
permit
--
Viktor.
Ralf Hildebrandt
> If the map is unlikely to ever contain an OK entry, a namaddr matchlist
> *may* be more appropriate than a map. This would also support CIDR
> notation.
>
> bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
>
> smtpd_sender_restrictions =
> permit_mynetworks,
> reject_bad_sender_mx,
> permit
This is perfect.
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
"I think there is a world market for maybe five computers."
- Thomas Watson, chairman of IBM, 1943.
Noel Jones
>* Victor....@morganstanley.com <Victor....@morganstanley.com>:
>
> > If the map is unlikely to ever contain an OK entry, a namaddr matchlist
> > *may* be more appropriate than a map. This would also support CIDR
> > notation.
> >
> > bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
> >
> > smtpd_sender_restrictions =
> > permit_mynetworks,
> > reject_bad_sender_mx,
> > permit
>
>This is perfect.
would be even more perfect if it supported the !exception notation, to
allow a local MX that might not actually be part of $mynetworks.
bad_mx_networks = 127/8, 10/8, 172.16/12, !10.1.1.15
--
Noel Jones
-
To unsubscribe from the postfix-users list, click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
Wietse Venema
> At 03:32 PM 3/21/03 +0100, Ralf Hildebrandt wrote:
> >* Victor....@morganstanley.com <Victor....@morganstanley.com>:
> >
> > > If the map is unlikely to ever contain an OK entry, a namaddr matchlist
> > > *may* be more appropriate than a map. This would also support CIDR
> > > notation.
> > >
> > > bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
> > >
> > > smtpd_sender_restrictions =
> > > permit_mynetworks,
> > > reject_bad_sender_mx,
> > > permit
> >
> >This is perfect.
>
> would be even more perfect if it supported the !exception notation, to
> allow a local MX that might not actually be part of $mynetworks.
>
> bad_mx_networks = 127/8, 10/8, 172.16/12, !10.1.1.15
This looks a lot like the old reject_maps_rbl restriction, where
the list was separate from the instance of use. That's not a big
deal, it just means we can't easily make the list context dependent.
What if a domain lists multiple MX addresses, some of which are
good, and some of which are bogus?
What if DNS lookup times out, does this mean we defer acceptance
with a temporary error reply code (because there might be a bad MX
address that we could not find out about) or do we give them the
benefit of the doubt?
Wietse
Victor....@morganstanley.com
> > bad_mx_networks = 127/8, 10/8, 172.16/12, !10.1.1.15
>
> This looks a lot like the old reject_maps_rbl restriction, where
> the list was separate from the instance of use. That's not a big
> deal, it just means we can't easily make the list context dependent.
>
The main reason that "reject_rbl_mumble <domain>" is the right answer is
that each "<domain>" represents a policy in its own right, not just a
single item being blocked.
To get context sensitivity for use of the MX blocking feature one would
most likely either apply or not apply the entire filter in the relevant
restrictions. It is hard to image individual elements of "bad_mx_networks"
being selectively applied (unlike individual RBL lists, which are outside
of one's control, vary in content and blocking policy, ...).
So I do not think that the bad mx networks (unlike RBL lists) are
likely to need be context dependent, but this intuition may be proved
wrong with experience...
Along the same lines, there was a request to be able to block sender
domains based on the NS records for the domains, this if implemented could
perhaps better be served by an access table.
> What if a domain lists multiple MX addresses, some of which are
> good, and some of which are bogus?
Now I remember the previous discussion of this topic. The
"bad_mx_networks" list should act as a filter, not a reject list. Bad MX
records are ignored, and sites with *only* bad MX records are caught by
"reject_unknown_sender_domain", because the reverse resolution brings back
an emtpy (after filtering) set of MX records.
> What if DNS lookup times out, does this mean we defer acceptance
> with a temporary error reply code (because there might be a bad MX
> address that we could not find out about) or do we give them the
> benefit of the doubt?
>
If the MX lookup times out or if DNS lookup of the A records of at least
one MX host times out, and no valid (per the appropriate bad network list)
addresses are found, "reject_unknown_sender_domain" sets defer_if_permit.
--
Viktor.
Noel Jones
>Now I remember the previous discussion of this topic. The
>"bad_mx_networks" list should act as a filter, not a reject list. Bad MX
>records are ignored, and sites with *only* bad MX records are caught by
>"reject_unknown_sender_domain", because the reverse resolution brings back
>an emtpy (after filtering) set of MX records.
>
> > What if DNS lookup times out, does this mean we defer acceptance
> > with a temporary error reply code (because there might be a bad MX
> > address that we could not find out about) or do we give them the
> > benefit of the doubt?
> >
>
>If the MX lookup times out or if DNS lookup of the A records of at least
>one MX host times out, and no valid (per the appropriate bad network list)
>addresses are found, "reject_unknown_sender_domain" sets defer_if_permit.
This is very close. I don't think we want to creates a dependency that
reject_unknown_sender_domain would need to follow reject_bad_mx, making the
documentation (more)? confusing.
The reject_unknown_sender_domain function would need to be included in the
reject_bad_mx restriction.
I don't remember the "filter" aspect being part of the previous discussion,
I think that would solve several problems nicely.
As for being context sensitive, I don't see a need for that either, but
undoubtedly someone can come up with a use for it. I could live with a
syntax such as (using all of these at once)
smtpd_XXX_restrictions =
...
reject_bad_mx 10/8
reject_bad_mx 127/8
reject_bad_mx hash:/etc/whatever
but this prevents something like "10/8 !10.1.1.15" from being a
possibility. I'm not sure which would be more useful to have.
- Noel
Victor....@morganstanley.com
> As for being context sensitive, I don't see a need for that either, but
> undoubtedly someone can come up with a use for it. I could live with a
> syntax such as (using all of these at once)
> smtpd_XXX_restrictions =
> ...
> reject_bad_mx 10/8
> reject_bad_mx 127/8
> reject_bad_mx hash:/etc/whatever
>
This does not work, because all the bad addresses need to be filtered out
together. Otherwise an MX record that lists both a 10/8 address and a
127/8 address passes both tests (10/8 allows 127/8 and 127/8 allows 10/8).
So the filter list needs to be a single list. And match lists already
support the "!" syntax.
--
Viktor.
Noel Jones
very well. I like the other syntax better anyway. I was just looking for
possible user interface to make it context sensitive if that was a concern.
- Noel
Ralf Hildebrandt
> This looks a lot like the old reject_maps_rbl restriction, where
> the list was separate from the instance of use. That's not a big
> deal, it just means we can't easily make the list context dependent.
>
> What if a domain lists multiple MX addresses, some of which are
> good, and some of which are bogus?
Interesting. I guess Postfix will try all MXes and get the mail
delivered somehow?
> What if DNS lookup times out, does this mean we defer acceptance
> with a temporary error reply code (because there might be a bad MX
> address that we could not find out about) or do we give them the
> benefit of the doubt?
temporary error reply code, like in the sender address verification.
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
Why you can't find your system administrators:
recovering from the paper cuts after printing out large chunks of aforementioned CDs
Ralf Hildebrandt
> "bad_mx_networks" list should act as a filter, not a reject list. Bad MX
> records are ignored, and sites with *only* bad MX records are caught by
> "reject_unknown_sender_domain", because the reverse resolution brings back
> an emtpy (after filtering) set of MX records.
That sounds good.
--
Ralf Hildebrandt Ralf.Hil...@charite.de
my current spamtrap partmap...@charite.de
http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
When machines and computers, profit motives and property rights are
considered more important than people; the giant triplets of racism,
militarism, and economic exploitation are incapable of being
conquered. -- Martin Luther King
Victor....@morganstanley.com
So, is this more "what if" material for the archives, or is someone
writing code for this? Is the tentative idea robust enough to warrant
implementation?
--
Viktor.
Wietse Venema
> > What if a domain lists multiple MX addresses, some of which are
> > good, and some of which are bogus?
>
> records are ignored, and sites with *only* bad MX records are caught by
> "reject_unknown_sender_domain", because the reverse resolution brings back
> an emtpy (after filtering) set of MX records.
In that case the name "bad_mx_networks" is misleading, and it
would be more appropriate to use "ignore_mx_networks" instead.
> > What if DNS lookup times out, does this mean we defer acceptance
> > with a temporary error reply code (because there might be a bad MX
> > address that we could not find out about) or do we give them the
> > benefit of the doubt?
That pretty much follows from the preceding discussion. If no valid
address is found and we were unable to look up all address information,
then "reject_unknown_sender_domain" sets the defer_if_permit flag.
Wietse
Wietse Venema
> Along the same lines, there was a request to be able to block sender
> domains based on the NS records for the domains, this if implemented could
> perhaps better be served by an access table.
Meaning, if one NS record is unacceptable, then reject all.
With MX records, it's the exact opposite: as long as one is acceptable
we're happy.
And then we have the dreaded permit_mx_backup feature, which accepts
as long as (the primary) MX passes a filter.
So we need three mechanisms.
- An ignore filter that causes Postfix to accept mail as long as
something gets through the filter (ignore_mx_networks).
- A whitelist filter that causes Postfix to accept mail as long as
something gets through the filter (permit_mx_networks).
- A blacklist mechanism that rejects at the first offense
(reject_mx_networks)
Looks like we we're past the requirements (reject domains with
blacklisted NS records, accept domains as long as some MX passes
some hoops).
We're getting into some serious design. Given the three mechanisms
of ignore/permit/reject_mx_networks this could get complicated.
Wietse
Marcio Merlone
Em Fri, 21 Mar 2003 10:56:25 -0500 (EST), wie...@porcupine.org (Wietse
Venema) escreveu:
> Noel Jones:
> > At 03:32 PM 3/21/03 +0100, Ralf Hildebrandt wrote:
> > > > bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
> > > >
> > > > smtpd_sender_restrictions =
> > > > permit_mynetworks,
> > > > reject_bad_sender_mx,
> > > > permit
> > >
> > >This is perfect.
(...)
> What if DNS lookup times out, does this mean we defer acceptance
> with a temporary error reply code (because there might be a bad MX
> address that we could not find out about) or do we give them the
> benefit of the doubt?
How about let the sysadmin choose between some possible behaviors?
mx_error_action = (DEFER | TEMP | ACCEPT)
bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
smtpd_sender_restrictions =
permit_mynetworks,
reject_bad_sender_mx,
permit
or else
defer_mx_networks = 127/8, hash:...
temp_mx_networks = 192.168/16
accept_mx_networks = 200.219/16
BTW, I put some well-known spammers' domains on my DNS and point their
MX to 127.0.0.1. This feature would be really nice! :)
--
Marcio Merlone
Gustavo Lozano
> Victor....@morganstanley.com:
> > > What if a domain lists multiple MX addresses, some of which are
> > > good, and some of which are bogus?
> >
> > Now I remember the previous discussion of this topic. The
> > "bad_mx_networks" list should act as a filter, not a reject list. Bad MX
> > records are ignored, and sites with *only* bad MX records are caught by
> > "reject_unknown_sender_domain", because the reverse resolution brings back
> > an emtpy (after filtering) set of MX records.
>
> In that case the name "bad_mx_networks" is misleading, and it
> would be more appropriate to use "ignore_mx_networks" instead.
>
ignore_mx_networks is a good configuration name, it can be a table like
Ralph suggested.
About the lookup times there is no problem, the filter should act just
in case of detecting an MX host with addresses within a non-public ip
pool.
I again suggest:
ignore_mx_networks = 192.168.x.x, 10.x.x.x,
hash:/etc/postfix/mx_ignore_networks
Regards!!
> > > What if DNS lookup times out, does this mean we defer acceptance
> > > with a temporary error reply code (because there might be a bad MX
> > > address that we could not find out about) or do we give them the
> > > benefit of the doubt?
>
> That pretty much follows from the preceding discussion. If no valid
> address is found and we were unable to look up all address information,
> then "reject_unknown_sender_domain" sets the defer_if_permit flag.
>
> Wietse
--
_________________ __________________
Gustavo A. Lozano Noldata Corporation
glo...@noldata.com Calle 46 No. 40-19
CTO Bogota D.C. Colombia
Noldata Corporation http://noldata.com
I know not with what weapons World War III will be fought,
but World War IV will be fought with sticks and stones.
Albert Einstein
This Message has been scanned for Virus Content using RAV Antivirus.
Get your copy of RAV Antivirus at Noldata, send mail to
sa...@noldata.com http://noldata.com
Victor....@morganstanley.com
>
> Em Fri, 21 Mar 2003 10:56:25 -0500 (EST), wie...@porcupine.org (Wietse
> Venema) escreveu:
>
> > Noel Jones:
> > > At 03:32 PM 3/21/03 +0100, Ralf Hildebrandt wrote:
> > > > > bad_mx_networks = 127/8, 10/8, 172.16/12, 192.168/16, hash:/...
> > > > >
> > > > > smtpd_sender_restrictions =
> > > > > permit_mynetworks,
> > > > > reject_bad_sender_mx,
> > > > > permit
> > > >
> > > >This is perfect.
> (...)
> > What if DNS lookup times out, does this mean we defer acceptance
> > with a temporary error reply code (because there might be a bad MX
> > address that we could not find out about) or do we give them the
> > benefit of the doubt?
>
>
> How about let the sysadmin choose between some possible behaviors?
>
No there is only one right choice. With imcomplete data we give an
incomplete response, anything else is wrong.
--
Viktor.
Wietse Venema
> How about let the sysadmin choose between some possible behaviors?
>
> smtpd_sender_restrictions =
> permit_mynetworks,
> reject_bad_sender_mx,
> permit
>
>
> defer_mx_networks = 127/8, hash:...
> temp_mx_networks = 192.168/16
> accept_mx_networks = 200.219/16
relay_mx_networks?
Wietse
Peter H. Coffin
Which is starting to sound like it wants to be a map...
--
"Only Irish coffee provides in a single glass all four essential food
groups: alcohol, caffeine, sugar, and fat."
-Alex Levine
Victor....@morganstanley.com
> Victor....@morganstanley.com:
> > Along the same lines, there was a request to be able to block sender
> > domains based on the NS records for the domains, this if implemented could
> > perhaps better be served by an access table.
>
> Meaning, if one NS record is unacceptable, then reject all.
>
Yes, this is based on the observation that spammers who switch
sender domains frequently, tend to have a fixed nameserver pool serving
their rapidly varying multitude of domains. So one can gain useful
temporary advantage in the arms race by blacklisting the nameserver
instead.
> With MX records, it's the exact opposite: as long as one is acceptable
> we're happy.
Yes, if we ignore bogus MX records, both in smtpd restrictions and in the
"smtp" delivery agent (perhaps not in the "relay" delivery agent via a
master.cf "-o ignore_mx_networks="), then having one or more acceptable
remaining MX records makes the destination valid.
> And then we have the dreaded permit_mx_backup feature, which accepts
> as long as (the primary) MX passes a filter.
>
Yes, but I suspect most users of permit_mx_backup probably don't bother
setting permit_mx_backup_networks. If they do set permit_mx_networks,
using the filtered MX list will give better results if they (unwisely)
point primary MX to a firewalled internal network, secondary to Internet
facing gateways, and tertiary to backup MX hosts at their ISP, the ISP can
then filter the internal network from the MX list, and promote the
secondary MX to primary, tertiary to secondary, ... Of course it is better
to get the user to use split DNS and not use externally unreachable
primary MX records.
> So we need three mechanisms.
>
> - An ignore filter that causes Postfix to accept mail as long as
> something gets through the filter (ignore_mx_networks).
It is not so much about accepting the mail, as about MX list pruning, not
accepting mail from sites whose MX prunes down to an empty list is a use
of the pruning in a new restriction, but the pruning also applies in the
"smtp" delivery agent when constructing the MX list.
>
> - A whitelist filter that causes Postfix to accept mail as long as
> something gets through the filter (permit_mx_networks).
Yes, but it may be worthwhile to find out whether anyone is using this...
>
> - A blacklist mechanism that rejects at the first offense
> (reject_mx_networks)
>
I don't know of any likely uses for reject_mx_networks yet,
something along the lines of "check_sender_domain_ns_access" is what I
remembered seeing a request for some ago.
> Looks like we we're past the requirements (reject domains with
> blacklisted NS records, accept domains as long as some MX passes
> some hoops).
>
> We're getting into some serious design. Given the three mechanisms
> of ignore/permit/reject_mx_networks this could get complicated.
>
I guess I envision a single MX filter that returns a pruned address list
from a set of MX records and indicates whether any of the lookups failed.
This filter would be used with either in reject_unknown_sender_domain and
reject_unknown_recipient_domain or in a new pair of restrictions, and of
course also in the "smtp" delivery agent. So that delivery to domains with
some valid MX records actually goes to same said MX records.
So I guess I don't see the complexity. I would implement the
ignore_mx_networks feature first, and look at
check_sender_domain_ns_access as an independent mechanism.
At some point it would be nice to have dynamically loadable restrictions
as well as dynamically loadable maps, but getting dlopen()/dlsym()
and moral equivalents working right on all supported platforms is not
easy, though Tcl and Perl have managed to get it working on a broad range
of platforms, as I recall getting AIX to work right took some time in Tcl.
--
Victor Duchovni
IT Security,
Morgan Stanley
_______________________________________________________________________
NOTICE: If received in error, please destroy and notify sender. Sender
does not waive confidentiality or privilege, and use is prohibited.
Marcio Merlone
Em Fri, 21 Mar 2003 13:57:58 -0500 (EST), wie...@porcupine.org (Wietse
Venema) escreveu:
> Marcio Merlone:
> > defer_mx_networks = 127/8, hash:...
> > temp_mx_networks = 192.168/16
> > accept_mx_networks = 200.219/16
>
> relay_mx_networks?
Or,
reject_mx_networks
hold_mx_networks or dunno_mx_networks or tempfail_* or ...
permit_mx_networks
Looks like this will never end....
--
Marcio Merlone
Victor....@morganstanley.com
>
> Em Fri, 21 Mar 2003 13:57:58 -0500 (EST), wie...@porcupine.org (Wietse
> Venema) escreveu:
>
> > Marcio Merlone:
> > > defer_mx_networks = 127/8, hash:...
> > > temp_mx_networks = 192.168/16
> > > accept_mx_networks = 200.219/16
> >
> > relay_mx_networks?
>
> Or,
>
> reject_mx_networks
> hold_mx_networks or dunno_mx_networks or tempfail_* or ...
> permit_mx_networks
>
Please avoid idle speculation... If you have a concrete detailed
suggestion for how to filter out mail from sites with bogus MX records,
please post it. If you have a specific detailed critique, of a
previous suggestion that is welcome as well. The above is neither.
--
Viktor.
Marcio Merlone
Em Fri, 21 Mar 2003 15:27:08 -0500 (EST),
<Victor....@morganstanley.com> escreveu:
Sorry about the speculation, I was just suggesting the name of the
feature. I am too lammer to suggest how the feature should work, the
level of the conversation is too high for me, so I wanted to help with
something.
Also, I thought Wietse was having some fun with this. BTW, looks like he
was also making some idle speculation with the question he made and I
answered; just following your logic. :)
I understand you were so concentrate with the thread and this broke the
line. But take a deep breath, stay cool and if something bothers you,
have some fresh air and look again if what you are going to say is
really necessary.
Now, tell me, what was Wietse asking me with "relay_mx_networks?"?
Perhaps I just misunderstood....
Regards,
--
Marcio Merlone
Victor....@morganstanley.com
>
> Now, tell me, what was Wietse asking me with "relay_mx_networks?"?
> Perhaps I just misunderstood....
>
The list of ignored MX addresses may be different for relay
destinations... because the relay destinations may connected via
non-public networks. But I don't think this requires a relay_mx_networks.
I am not sure what he meant. Ask him. Perhaps it was sarcasm...
--
Viktor.
Clifton Royston
> At some point it would be nice to have dynamically loadable restrictions
> as well as dynamically loadable maps, but getting dlopen()/dlsym()
> and moral equivalents working right on all supported platforms is not
> easy, though Tcl and Perl have managed to get it working on a broad range
> of platforms, as I recall getting AIX to work right took some time in Tcl.
Wouldn't this violate Wietse's principle of not trusting user-
provided code of unknown quality inside Postfix itself, so that Postfix
can make some meaningful security guarantees? I don't believe there is
any way for a program to shield itself from the actions of a dl'd
library.
As I understood it, we are waiting on the socket-based (TCP) map type
for similar functionality.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- clif...@lava.net
"If you ride fast enough, the Specialist can't catch you."
"What's the Specialist?" Samantha says.
"The Specialist wears a hat," says the babysitter. "The hat makes noises."
She doesn't say anything else.
Kelly Link, _The Specialist's Hat_
Wietse Venema
Not really.
We're partitioning MX hosts by network whitelists, blacklists,
ignorelists. I was wondering if we had covered all the mechanisms,
or whether another partitioning scheme would need to be considered.
relay_mx_networks looks like just another whitelist filter.
If we can translate our "it would be soo cool" requirements into
sensible lower-level orthogonal concepts (such as whitelist,
blacklist, ignorelist, keeplist) then the result might be more
useful than a bunch of hard-coded features.
Since we are targeting a lot of DNS lookup it better be done
in an organzied manner.
I like solutions that involve multiple levels of abstraction.
Wietse
José Luis Tallón
>
>At some point it would be nice to have dynamically loadable restrictions
>as well as dynamically loadable maps, but getting dlopen()/dlsym()
>and moral equivalents working right on all supported platforms is not
>easy, though Tcl and Perl have managed to get it working on a broad range
>of platforms, as I recall getting AIX to work right took some time in Tcl.
Well, Debian actually has a working implementation of dynamic-loadable maps
and dynamically linked postfix available, thanks to Lamont Jones' excellent
work.
IIRC, Wietse has some reserves about the implementation details.
We might be approaching the moment were an "official" implementation of
loadable maps might be wise to have -- Initially maybe restricted to some
selected platforms such as Linux and Solaris --, maybe even based on
Lamont's patches.
We must keep in mind that advantages of dynamic-loadable maps and
dynamically linked postfix ( libglobal et al. ) are mostly flexibility,
since low memory usage ( due to Copy On Write techniques used in Un*x
kernels ) would only be noticeable in very thight memory scenarios.
Regards,
J.L.