import problem of "objectclass:: (/Base64)<groupOfNames>



MailNews Core
LDAP Integration
10 years ago
3 years ago


(Reporter: Ben, Unassigned)


Firefox Tracking Flags

(Not tracked)




10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20070725 Firefox/
Build Identifier: thunderbird version (20070728)

I think think t will be a simple solvable problem for your developers...

Code of my bash-converting function...

function f_convert_latin1_to_base64 {

    if [ -n ${#_result} ]; then
        # write content to file
        echo -e -n "${_result}" >

        # encode content
        # step 1......... from "latin1" into "utf-8"
        # step 2......... from "utf-8"  into "/Base64"
        # or in one step
        # step 1......... from "latin1" into "/Based64"
        recode latin1../Base64

        # restore joined lines
        set --
        while read line "${@}"
        done <

        # clean space
        [ -f "" ] && rm

        # return result
        echo -n "${_result}"
        echo -n ""


I used for a simple test the export-content of one special prepared "addressbook"
"application"->"thunderbird::addressbook" the simple solution with the function

I can encode every modifyable content I extract by the example export from the
"thunderbird::addressbook" in /Base64.
With example given here for a phone number entry:

# "telephoneNumber:: <work-phonenumber>"
   buffer="telephoneNumber:: "
[-n "${element_list[${pos[10]}]}" ] && rawbuffer="${element_list[${pos[10]}]}"
echo "${buffer}$( f_convert_latin1_to_base64 ${rawbuffer} )"

To simpliy code for you, replace the "element_list[${pos[10]}]" with
a "phonenumber"

element_list[${pos[...]}] realizes for my import-process a flexible filter

I can encode every modifyable content, except the necessary one for creating
email-lists. Here I am forced to use:

echo "objectclass: groupOfNames"

If I use

echo "objectclass: $( f_convert_latin1_to_base64 "groupOfNames" )"

then the wanted email-address-list will not be imported/created.

I think there have someone forgotten to implement the "/Base64"-support,
if your addressbook-importfilter gets "objectclass:: ...".

Thanks for feedback,

Reproducible: Always

Steps to Reproduce:
1. see Details
Actual Results:  
work around is explained in Details

Expected Results:  
Repair of bug in future.

Merci beaucoup!


10 years ago
Version: unspecified → 2.0
Mark, do you think this is something we should support? Is it really in the spirit of RFC 2849?
Component: Address Book → MailNews: LDAP Integration
Product: Thunderbird → Core
QA Contact: address-book → ldap-integration
Version: 2.0 → unspecified

Comment 2

10 years ago
I am not sure I understand what the bug is here... is it that a line like this:


is not recognized as specifying the value groupOfNames for objectClass?  I would say that is a bug (I would also say it is unusual to encode strings as Base64 when they do not contain any special characters).


9 years ago
Product: Core → MailNews Core

Comment 3

7 years ago
ben, do you agree with the question, and the analysis of comment 2?

Comment 4

7 years ago
Thanks a lot to all of you and for your feedback.

2007 is a realy long time ago, since I got to solve described problem with
import/export contact-data from and to Thunderbird.
The first and easiest way for me was solving my problem in bash.

What I can remember is, that special Characters like "äÄöÖüÜ" a.s.o
had made me some troubles during such a process, if I used it without the
transformation above. ASCII do not support these characters and the english
language has got no need in using "äÄöÖüÜ".

I made a quick look to my test-data, I saw that my described encoding was
always marked by an extra ":". "::" instead of a single ":"
So, it can really be, that in the line of phonenumber a single ":" marks
a non-encoded phonenumber, which, if the number would be right encoded,
has to be marked with "::"

I am sorry, that I can not give more help.
Problems I solved final in the past, would not be so often touched a second time.

@Mark Smith
You have right. There is no need for transformation, even it is necessary.

My quick patch do not check cases if necessary, or if not necessary
to use the transformation above. I did it for all, because it was the easiest
and quickest way. Once content importet into Thunderbird nobody will ask me
what encoding was taken for import. My customer was happy after process
run properly without any problems. ;-D

If think this thread can be closed, if the marks ":" for plain-text and "::" for encoded text were working right during import/export process.
You need to log in before you can comment on or make changes to this bug.