Re: ldap_table and insignificant spaces
- On Wed, Mar 06, 2013 at 03:51:28AM +0000, Viktor Dukhovni wrote:
> On Fri, Mar 01, 2013 at 03:19:42PM +0100, Bastian Blank wrote:I forgot that, yes.
> > - The ldap server sanitices the query to (mail=test@...) as
> > mandated by RFC 4717, 4.2.3; it removes the insignificant space.
> I see the "insignificant space handling" defined in 4518 (referenced
> from 4517).
> It seems to suggest that exact string matches should take the formThis stunt is done to support working substring matches. It does not
> where any spaces inside the value are encoded as <SPACE><SPACE>.
help here and you can't trick it by adding more spaces.
> Is this backwards compatible with older LDAP servers that are notLDAPv3 was always UTF-8 based.
> UTF-8 based?
> An easy way to achieve this would be:No, this won't help, as the syntax rules will sanitize also the
> query_filter = (mail = %s )
> if such spaces are not removed at a higher level by the LDAP library.
> Does this help?
> > Not sure if something should be done about it. At least it is aI don't think this would be a good idea. It still includes a N-to-1
> > surprising outcome for a simple question; while both parties works
> > perfectly fine.
> Another thing that could help is if Postfix would use the "external"
> form of the address:
> " test"@...
> with the quotes as the query string.
mapping of spaces.
I think in this case all queries including spaces should be ignored by
ldap_table, because of the way LDAP works with them.
> I seem to recall that this isThis makes sense. In my tests such addresses where not rewritten as
> already the case with lookup keys in virtual_alias_maps, but it
> may not be the case with other tables.
> Which Postfix "mumble_maps"transport, virtual_alias, virtual_alias_domains, virtual_mailbox,
> parameter are you using with LDAP?
virtual_mailbox_domains, relay_recipient, relay_domains
All your people must learn before you can reach for the stars.
-- Kirk, "The Gamesters of Triskelion", stardate 3259.2
- Viktor Dukhovni:
> On Tue, Mar 05, 2013 at 11:16:18PM -0500, Wietse Venema wrote:Oh, and did I mention that some lookup tables are used for both
> > Viktor Dukhovni:
> > > Arguably, all lookup keys in tables should be in "external" (RFC-5322)
> > > form. The suggested doubling of internal spaces is far less important
> > > in practice that avoiding the loss of leading spaces.
> > Which external form?
> > - RFC 5321 and 5322 have different rules.
> I was a bit sloppy in my wording, I guess 5321 is the right one
> for processing envelope addresses, and perhaps 5322 for processing
> header addresses (with canonical and generic rewrites for example).
headers and envelopes, which have different quoting rules and
therefore different "external" forms?
> This complicates recipient extension support, since to compute anIt may be more productive to add a dbcommon etc. flag that says
> address sans extension we'd need to dequote, lose the extension
> and then requote (using the right quoting style). This is not
query with the external form of an address (but keep using internal
forms in Postfix itself).
> > - Worse, The mappings are not one-to-one. That is, there are multiple
> > correct implementations for quote_821_local() and quote_822_local().
> So long as we pick something consistent and documented, users can
> likely adapt their table keys. In most cases the external form
> and the internal form are identical, but the exceptions are a pain.
> For this specific LDAP issue, if changing the query works that's
> the fastest path to success, and we can adjust the ldap_table(5)
> document with the latest best practice syntax.
> The more things change, the less they stay the same. :-)