Hi guys,
When searching for Chinese names in the "to:" field under Thunderbird, I get an assertion failing in slapd. I see that this is because the "mail" attribute in the default schema is of type "IA5 String" but the Chinese name that I'm searching for falls outside the character set.
The work around I have is to modify the "mail" attributetype in the core.schema from:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
to:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Can anyone see a problem with the above, or is there a better way of accomplishing this?
Thanks
Alfie
Am Tue, 07 Feb 2012 13:10:36 +1100 schrieb Alfie John alfiej@opera.com:
Hi guys,
When searching for Chinese names in the "to:" field under Thunderbird, I get an assertion failing in slapd. I see that this is because the "mail" attribute in the default schema is of type "IA5 String" but the Chinese name that I'm searching for falls outside the character set.
The work around I have is to modify the "mail" attributetype in the core.schema from:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
to:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Can anyone see a problem with the above, or is there a better way of accomplishing this?
Never modify a standard track attribute type, all you can do is to create a subtype of mail. On the other hand, your intention does not comply to RFC-5322 which requires that header fields MUST be composed of printable US-ASCII characters.
-Dieter
On 02/07/2012 08:56 AM, Dieter Klünter wrote:
Am Tue, 07 Feb 2012 13:10:36 +1100 schrieb Alfie Johnalfiej@opera.com:
Hi guys,
When searching for Chinese names in the "to:" field under Thunderbird, I get an assertion failing in slapd. I see that this is because the "mail" attribute in the default schema is of type "IA5 String" but the Chinese name that I'm searching for falls outside the character set.
The work around I have is to modify the "mail" attributetype in the core.schema from:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
to:
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Can anyone see a problem with the above, or is there a better way of accomplishing this?
Never modify a standard track attribute type, all you can do is to create a subtype of mail. On the other hand, your intention does not comply to RFC-5322 which requires that header fields MUST be composed of printable US-ASCII characters.
In addition, I suggest you check whether the problem persists with the latest release; in case, please file an ITS following instructions here http://www.openldap.org/faq/data/cache/56.html.
p.
On Tue, Feb 7, 2012, at 09:14 AM, Pierangelo Masarati wrote:
In addition, I suggest you check whether the problem persists with the latest release; in case, please file an ITS following instructions here http://www.openldap.org/faq/data/cache/56.html.
Thanks for the pointer.
I was using Debian's upstream which I doubt is the latest release. I'll look tomorrow.
I don't think filing a bug is the correct thing to do since as Dieter pointed out the problem is with bogus mail applications breaking the RFC and not a bug in OpenLDAP. However with the practicality of using UTF-8 for the mail attribute value is pragmatic. Thoughts?
Alfie
On 02/07/2012 12:57 PM, Alfie John wrote:
On Tue, Feb 7, 2012, at 09:14 AM, Pierangelo Masarati wrote:
In addition, I suggest you check whether the problem persists with the latest release; in case, please file an ITS following instructions here http://www.openldap.org/faq/data/cache/56.html.
Thanks for the pointer.
I was using Debian's upstream which I doubt is the latest release. I'll look tomorrow.
I don't think filing a bug is the correct thing to do since as Dieter pointed out the problem is with bogus mail applications breaking the RFC and not a bug in OpenLDAP. However with the practicality of using UTF-8 for the mail attribute value is pragmatic. Thoughts?
If, as you say, slapd asserts, then there's also a bug in the code, since invalid data should be catched earlier. Fixing this has little to do with solving your problem, but would improve the software.
p.
On Tue, Feb 7, 2012, at 02:19 PM, Pierangelo Masarati wrote:
If, as you say, slapd asserts, then there's also a bug in the code, since invalid data should be catched earlier. Fixing this has little to do with solving your problem, but would improve the software.
Sorry for the confusion.
When I said slapd assets, I didn't mean assert() but asserted_value_validate_normalize() does not return LDAP_SUCCESS in filter.c. So it's not a bug in slapd.
Alfie
Am Tue, 07 Feb 2012 22:57:31 +1100 schrieb Alfie John alfiej@opera.com:
On Tue, Feb 7, 2012, at 09:14 AM, Pierangelo Masarati wrote:
In addition, I suggest you check whether the problem persists with the latest release; in case, please file an ITS following instructions here http://www.openldap.org/faq/data/cache/56.html.
Thanks for the pointer.
I was using Debian's upstream which I doubt is the latest release. I'll look tomorrow.
I don't think filing a bug is the correct thing to do since as Dieter pointed out the problem is with bogus mail applications breaking the RFC and not a bug in OpenLDAP. However with the practicality of using UTF-8 for the mail attribute value is pragmatic. Thoughts?
All you could do, is creating a new private attribute type with syntax directory string and configure applications to use this new attribute type.
-Dieter
On Tue, Feb 7, 2012, at 02:49 PM, Dieter Klünter wrote:
All you could do, is creating a new private attribute type with syntax directory string and configure applications to use this new attribute type.
As I said before we have no control over user environments, so configuring applications to use a private attribute is not an option for us.
Alfie
Hi Dieter,
On Tue, Feb 7, 2012, at 08:56 AM, Dieter Klünter wrote:
Never modify a standard track attribute type, all you can do is to create a subtype of mail. On the other hand, your intention does not comply to RFC-5322 which requires that header fields MUST be composed of printable US-ASCII characters.
Unfortunately I'm not in control of what mail clients users are running. This particular case was Thunderbird, but I assume that Apple Mail is also sending bogus UTF-8 mail attribute values.
Alfie
On Tuesday, 7 February 2012 13:52:59 Alfie John wrote:
Hi Dieter,
On Tue, Feb 7, 2012, at 08:56 AM, Dieter Klünter wrote:
Never modify a standard track attribute type, all you can do is to create a subtype of mail. On the other hand, your intention does not comply to RFC-5322 which requires that header fields MUST be composed of printable US-ASCII characters.
As far as I can tell, the issue is not to be able to have UTF-8 in the mail attribute, but allow the client's search to succeed, where it uses a filter of the form:
(|(cn=%s)(sn=%s)(mail=%s))
In the case where the user tries to search for a UTF-8 character (which is present in the target entries cn or sn values), the client sends UTF-8 in the mail=%s portion.
Unfortunately I'm not in control of what mail clients users are running.
That doesn't prevent you from filing bugs on said mail clients. Please file a bug with Thunderbird.
This particular case was Thunderbird, but I assume that Apple Mail is also sending bogus UTF-8 mail attribute values.
Because one implementation has a bug, other implementations of similar functionality *must* have it?
Regards, Buchan
On Wed, Feb 8, 2012, at 01:06 PM, Buchan Milne wrote:
As far as I can tell, the issue is not to be able to have UTF-8 in the mail attribute, but allow the client's search to succeed, where it uses a filter of the form:
(|(cn=%s)(sn=%s)(mail=%s))
In the case where the user tries to search for a UTF-8 character (which is present in the target entries cn or sn values), the client sends UTF-8 in the mail=%s portion.
Yep, that's what is happening.
Unfortunately I'm not in control of what mail clients users are running.
That doesn't prevent you from filing bugs on said mail clients. Please file a bug with Thunderbird.
I filed a bug with Apple and Mozilla this morning.
This particular case was Thunderbird, but I assume that Apple Mail is also sending bogus UTF-8 mail attribute values.
Because one implementation has a bug, other implementations of similar functionality *must* have it?
No, but because searches from Apple Mail were breaking too. The value for "mail" from Apple Mail is not only in UTF-8, but it is splitting two Chinese characters like:
sprintf( "(&(|(cn=%s*)(mail=%s*)(sn=%s*))(|(cn=%s*)(mail=%s*)(sn=%s*)))", first_char, first_char, first_char, second_char, second_char, second_char, );
From my basic understanding, this is searching for a "mail" starting with first_char, and then ANDing it with a "mail" starting with second_char.
Alfie
openldap-technical@openldap.org
-
Alfie John -
Buchan Milne -
Dieter Klünter -
Pierangelo Masarati