From: Liviu Daia (Liviu.Daiaimar.ro)
Date: Mon Dec 01 2003 - 16:08:16 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 1 December 2003, <Victor.Duchovnimorganstanley.com> wrote:
> On Mon, 1 Dec 2003, Liviu Daia wrote:
>
> > My initial motivation for this was related to enhancing the
> > behaviour of LDAP maps, but this mechanism could be interesting in
> > general. Aside from the obvious uses as "pipes", map chains would
> > be a clean solution for operations such as input or output quoting
> > (thing RFC 2253 for LDAP, and SQL quoting), and result validation.
>
> Quoting is a complex issue, because for multi-valued lookups it may be
> too late to quote the result elements (when unquoted elements contain
> the "," element delimiter).

    There are actually two problems here: keeping multiple results
separate, and handling quoting when the string to be quoted is composed
of substrings that should be quoted using different rules (say, LDAP
URIs). I'll address the first problem below. The second problem is
more punctual, and I'd prefer to ignore it for now. :-)

> This said, filtering and other post-processing will likel be useful in
> a variety of contexts.
>
> > I suggest the syntax
> >
> > chain:/path/to/file
> >
> > where "/path/to/file" would be a plain file containing a list of
> > maps. This would allow map chains to be used just like other maps.
>
> This does solve the problem of how to include chains in access maps
> without changing the restriction parser.

    Also, that's by far the easiest choice.

> On the other hand some users prefer to put as much of the
> configuration as possible into main.cf. One could (somewhat along
> the lines of the backwards compatibility hooks in the snapshot LDAP
> driver) also support chain:parameter_prefix, or even a more complex
> fully inlined form chain:{multi line data} which requires parser
> changes.

    That sounds like a lot of complex code, for little return. My
personal choice would be to either make the inline syntax obsolete for
LDAP, or else add some general "grouping" mechanism to main.cf and make
the external syntax for LDAP / MySQL / PgSQL obsolete. The grouping
mechanism could also be used to provide "subroutines" to smtpd checks.
But this too should probably be left for later.

> > From the point of view of implementation, the only complication is
> > related to handling intermediate multiple results, more precisely
> > parsing them from the output of the plain maps. Obviously, this
> > makes sense for the maps that return lists of addresses, but not
> > otherwise.
>
> Yes, the interpretation of results with embedded commas needs to be
> configurable on a per chain or even map within chain basis.

    The way I see it, there are two ways to support multiple results: a
minimal one, and a maximal one. The minimal way is to split the results
at the familiar whitespace-or-comma, and let the user request the split
explicitly by adding a flag to the given map whose results are to be
split. We then trust the user to know what she's doing. :-) The maximal
way is to add support for true multi-valued maps, and add a "join"
filter, for compatibility with the rest of Postfix. The caller would
then request the results as either an array of items, or a flat list.
This way multiple results would be kept separate until the very last
moment.

    The minimal way could be enhanced by making the split pattern
configurable, but that might raise various safety problems. Obviously,
the maximal is cleaner, but the changes to the code would be more
complex.

    While we are at it: if we decide to go with the troubles of the
maximal way, we might also make map lookups case sensitive, and
implement case folding as a filter. We can even have case folding only
for the domain part.

> > And whether a map is supposed to return address lists depends only
> > on the context in which the map is used, not on the map itself. So
> > far, the best way I can think of to handle this would be to add a
> > flag to the individual maps in "/path/to/file", instructing the
> > chain to split the result into multiple addresses at that point.
> >
>
> This seems reasonable. The chain map should come with a few in-line
> filters. It might even be reasonable to use printf-like templates for
> simple in-line filters which take data from the *original* input key
> and/or the output of the previous map (current input key).

    This makes sense, but it also means the filter couldn't work in
complete isolation of the other maps (it would need access to the
initial input key). Would that be useful for anything else than
LDAP? The advantage of isolated filters would be that they could be
implemented as external programs. Then again, there's nothing wrong
with having both kinds.

> This would subsume some of the functionality of the LDAP changes
> proposed by Diego Rivera. Some of the LDAP specific issues will not go
> away, unless the LDAP maptype is augmented with an "ldapuri" maptype
> that can map an input URI (base, scope, filter) and an input key to a
> result set.

    That's one of the reasons I was insisting on having a map that would
take LDAP URIs on input.

> One would also need to be able to specify RFC225[34] quoting of
> dynamic parts of the URI.

    Here two, there are two ways of doing it. The first is to support
full URI syntax on input, as above. The second is to make the map
flexible enough to be able to read its key specifications (base, filter
etc.) on input (using, of course, some simple protocol). The LDAP URI
results would then be delegated to a filter that would parse the URI
into components, and a "flexible" map that would take its specifications
on input. Plain LDAP maps could also be "modularized" into a parser and
a "flexible" map. IMO the second way seems cleaner.

> The "dumbing down" of LDAP after chains are implemented is not an
> immediate requirement, but is a reasonable design goal, because then
> the LDAP maptype will be less "special" with the bells and whistles
> provided by the chaining layer.

    Yes, dict_ldap is a Christmas Tree of features as it is now. That
was my initial motivation.

> The key question I think, is whether the more general framework will
> be understood by the users! Perhaps the current set of "just-right"
> if ad-hoc mechanisms has more to offer in its simplicity than a more
> general approach will have to offer in its flexibility. I don't think
> that as a mathematician by training I am qualified to answer this
> question, I find abstract systems *easier* to understand :-)

    With the right design, the general mechanisms should be simpler than
the particular ones. But then again, as a mathematician by formation,
I'm probably even worse than you at this.

    Regards,

    Liviu Daia

--
Dr. Liviu Daia e-mail: Liviu.Daiaimar.ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]