I've just tried it with the "§ogo" password for a test user and it works for me.

Set that password to a test user and send me the ldif entry including the userPassword.

Here is the ldif:
dn: uid=tt,ou=TMP,ou=Users,dc=brain-biotech,dc=de
userPassword: {CRYPT}$1$qy6NiLx5$lgq8dF3GukYOvWzyYuXSm/
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: mailUser
objectClass: organizationalPerson
objectClass: person
gidNumber: 513
loginShell: /bin/false
givenName: test
sn: test
displayName: test, test
uid: tt
homeDirectory: /home/tt
mail: tt@brain-biotech.de
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
maildrop: tt@brain-biotech.de
cn: test, test
uidNumber: 24628

In the Webinterface I get login failed wrong password.The Crash I described only happens in Thunderbird. I still need to test this with this new user.
The password here was §sogo

Error log:
Aug 09 15:40:40 sogod [3079]: <0x0x7f3efd93faf8[LDAPSource]> <NSException: 0x7f3efdbd94f8> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{login = "uid=tt,ou=tmp,ou=users,dc=brain-biotech,dc=de"; }
Aug 09 15:40:40 sogod [3079]: SOGoRootPage Login from '192.168.0.25' for user 'tt' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0

Will test in TB and report back.

OK tried with TB under Linux and I can reproduce ist:

Here is what I see in the logs:
192.168.0.25 - - [12/Aug/2013:08:30:23 GMT] "OPTIONS /SOGo/dav/tt/Contacts HTTP/1.1" 401 28/0 0.005 - - 388K
Aug 12 08:30:23 sogod [3074]: <0x0x7f3efd3e74b8[WOWatchDogChild]> child 8626 exited
Aug 12 08:30:23 sogod [3074]: <0x0x7f3efd3e74b8[WOWatchDogChild]> (terminated due to signal 6)
Aug 12 08:30:23 sogod [3074]: <0x0x7f3efd3e74b8[WOWatchDogChild]> avoiding to respawn child before 2013-08-12 08:30:28 +0200
Aug 12 08:30:23 sogod [8627]: <0x0x7f3efd87b648[SOGoDAVAuthenticator]> got malformed basic credentials (missing colon)!
192.168.0.25 - - [12/Aug/2013:08:30:23 GMT] "OPTIONS /SOGo/dav/tt/Contacts HTTP/1.1" 401 28/0 0.001 - - 0
glibc detected /usr/sbin/sogod: double free or corruption (fasttop): 0x00007f3efd8733d0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x760e6)[0x7f3ef94530e6]
/usr/lib64/libgnustep-base.so.1.23(+0x3154a6)[0x7f3efa3594a6]
/usr/lib64/libgnustep-base.so.1.23(NSZoneFree+0x38)[0x7f3efa35c454]
/usr/lib64/libgnustep-base.so.1.23(+0x1871f6)[0x7f3efa1cb1f6]
/usr/lib64/libgnustep-base.so.1.23(+0x2671f8)[0x7f3efa2ab1f8]
/usr/lib64/libgnustep-base.so.1.23(+0x1a14c8)[0x7f3efa1e54c8]
/usr/lib64/libgnustep-base.so.1.23(+0x1a1235)[0x7f3efa1e5235]
/usr/lib64/libgnustep-base.so.1.23(+0x1a11eb)[0x7f3efa1e51eb]
/usr/lib64/libNGObjWeb.so.4.9(+0x1c05ac)[0x7f3efbb505ac]
/usr/lib64/libgnustep-base.so.1.23(+0x256717)[0x7f3efa29a717]
/usr/lib64/libgnustep-base.so.1.23(+0x256a3a)[0x7f3efa29aa3a]
/usr/lib64/libgnustep-base.so.1.23(+0x2568c9)[0x7f3efa29a8c9]
/usr/lib64/libNGExtensions.so.4.9(+0x6207a)[0x7f3efaf1a07a]
/usr/lib64/libgnustep-base.so.1.23(+0x376c09)[0x7f3efa3bac09]
/usr/lib64/libgnustep-base.so.1.23(+0x2a68c6)[0x7f3efa2ea8c6]
/usr/lib64/libgnustep-base.so.1.23(+0x2a6cd5)[0x7f3efa2eacd5]
/usr/lib64/libNGObjWeb.so.4.9(+0x119e70)[0x7f3efbaa9e70]
/usr/sbin/sogod(+0x6f1d)[0x7f3efd08cf1d]
/usr/lib64/libNGObjWeb.so.4.9(+0x168b91)[0x7f3efbaf8b91]
/usr/lib64/libNGObjWeb.so.4.9(+0x16900d)[0x7f3efbaf900d]
/usr/lib64/libNGObjWeb.so.4.9(+0x1697da)[0x7f3efbaf97da]
/usr/lib64/libNGObjWeb.so.4.9(+0x16a9be)[0x7f3efbafa9be]
/usr/lib64/libNGObjWeb.so.4.9(WOWatchDogApplicationMain+0x5ed)[0x7f3efbafb211]
/usr/sbin/sogod(main+0x111)[0x7f3efd08c0ed]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f3ef93fbcdd]
/usr/sbin/sogod(+0x5f09)[0x7f3efd08bf09]
======= Memory map: ========
7f3ee9450000-7f3ee949f000 r-xp 00000000 fd:00 552277 /lib64/libldap_r-2.4.so.2.5.6
7f3ee949f000-7f3ee969e000 ---p 0004f000 fd:00 552277 /lib64/libldap_r-2.4.so.2.5.6
7f3ee969e000-7f3ee96a0000 r--p 0004e000 fd:00 552277 /lib64/libldap_r-2.4.so.2.5.6
7f3ee96a0000-7f3ee96a2000 rw-p 00050000 fd:00 552277 /lib64/libldap_r-2.4.so.2.5.6
7f3ee96a2000-7f3ee96a4000 rw-p 00000000 00:00 0
7f3ee96a4000-7f3ee96ca000 r-xp 00000000 fd:00 275595 /usr/lib64/libpq.so.5.2
7f3ee96ca000-7f3ee98c9000 ---p 00026000 fd:00 275595 /usr/lib64/libpq.so.5.2
7f3ee98c9000-7f3ee98cc000 rw-p 00025000 fd:00 275595 /usr/lib64/libpq.so.5.2
......

Here is the SOGoUserSources part of our config:

SOGoUserSources = (
{
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = "ou=Users,dc=brain-biotech,dc=de";
bindDN = "cn=Directory Manager";
bindFields = (
uid
);
bindPassword = "password";
canAuthenticate = YES;
displayName = BRAIN;
encryption = STARTTLS;
hostname = "ldap.brain-biotech.de lx-sv-08.brain-biotech.de";
id = BRAIN;
isAddressBook = YES;
port = 389;
},

Can you get a pcap on 127.0.0.1:20000 when doing this request? I'd like to see the actual payload that crashes sogo.

I haven't been able to reproduce this issue here with the ldif you provided, in fact I can't bind with the password '§sogo' (or §ogo)

Will try an d get back to you. Might take a while. The Password by the way is §sogo and it is in a MD5-Crypt hash. We are using 389-Directory server. If you can't reproduce it I think it might be related to LDAP. We will see.

attached the tcpflow output. Command was:
tcpflow -c -i lo tcp port 20000

Ok, it looks like thunderbird is sending the password in the iso8859-1 encoding, which is causing some issues in sope (double free + crash)

I'll see what we can do about that.

This should be fixed now: https://github.com/inverse-inc/sope/commit/dbf040d834cd6d49d3d8d98640d7c0fc12415e5a

Do you have a test environment where you could test the next nightly builds?
Also, which distro/arch are you using, I'll launch the builds for your distro if you can test it today.

We use Centos6. Havent't got a test environment but SOGo is running on a VM so I'll be able to test at off-hours. I'll be able to test in the last week of september. Thanks

I'll close the bug for now since I believe it is fixed. Reopen if needed after testing.

Tried it with a test VM and the crash is gone. However I still can't login. You said before that you couldn't reproduce the crash but couldn't login using the LDIF and the password §sogo. This is the situation I have now.

If you need more info let me know.

OK. Solved the problem. It was in the software I used for setting the password. Sorry. So this is solved now.

Was it setting the password using latin1 (iso8859-1) encoding before using crypt on it?