Re: [Dovecot] Password authentication and character set
19.11.2008 01:34, Geert Hendrickx wrote: On Tue, Nov 18, 2008 at 10:00:00PM +0200, Fredrik Grönqvist wrote: Yes, I see. So in light of this and the conversation on the imap-protocol -list http://mailman2.u.washington.edu/pipermail/imap-protocol/2008-February/000822.html our current options seem to boil down to having the passwords ISO-8859-1 encoded (given the demographics of our users). Those using operating systems with native UTF-8 clients have to use passwords containing only 7-bit characters. Actually I would do it the other way around. You can't really explain to your UTF-8 using users "you should use that older client instead of this newer one to make your login work". And some day you'll have to switch to UTF-8 anyway. Yes, I agree that it should be in UTF-8. My specific problem is that about 80% (a rough estimate) of our users are on either Windows or webmail. Those having passwords containing umlauts etc can log on, using their current client, if the passwords are kept ISO-8859-1 encoded instead of UTF-8. I didn't realise the specifications were so flexible on this password issue. s/flexible/vague/ :-) The consensus on the imap-protocol list, and particularly the message you refer to, seems to be "we should replace ASCII with UTF-8 in the spec". It does seem that way, and while I think it will be increasingly important in the future, I also got the feeling that this change will take a long time to filter down to the implementations (as both servers and clients need to change). As Timo pointed out, the options to "fix" this on the server side are currently quite limited, so it seems I have to stick to the lowest common denominator in our password policy. Chears, Fredrik
Re: [Dovecot] Password authentication and character set
On Tue, Nov 18, 2008 at 10:00:00PM +0200, Fredrik Grönqvist wrote: > Yes, I see. So in light of this and the conversation on the imap-protocol > -list > > http://mailman2.u.washington.edu/pipermail/imap-protocol/2008-February/000822.html > > > > our current options seem to boil down to having the passwords ISO-8859-1 > encoded (given the demographics of our users). > Those using operating systems with native UTF-8 clients have to use > passwords containing only 7-bit characters. Actually I would do it the other way around. You can't really explain to your UTF-8 using users "you should use that older client instead of this newer one to make your login work". And some day you'll have to switch to UTF-8 anyway. > I didn't realise the specifications were so flexible on this password > issue. s/flexible/vague/ :-) The consensus on the imap-protocol list, and particularly the message you refer to, seems to be "we should replace ASCII with UTF-8 in the spec". Geert
[Dovecot] Disconnecting without unbinding?
Timo Please have a look at this short thread[1]. That message stops appearing whenever I shutdown dovecot. I'm using dovecot 1.0.15. dovecot-ldap.conf - dn = ... dnpass = ... ldap_version = 3 auth_bind = no base = ... pass_filter = ... pass_attrs = ... user_filter = ... user_attrs = ... default_pass_scheme = MD5-CRYPT user_global_uid = vmail user_global_gid = vmail Regards, maykel [1] http://www.openldap.org/lists/openldap-software/200811/msg00078.html --- Red Telematica de Salud - Cuba CNICM - Infomed
Re: [Dovecot] pam_start() failed: system error
On Tue, Nov 18, 2008 at 06:20:14PM +0200, Timo Sirainen wrote: > On Tue, 2008-11-18 at 16:02 +0100, Peter Orlowski wrote: > > > > Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't > > contact LDAP server > > Set to nonzero: > > # Number of auth requests to handle before destroying the process. This may > # be useful if PAM plugins leak memory. > #auth_worker_max_request_count = 0 > > > I have tried different settings for worker_max_count, Thank you. It seems I got those two confused, sorry. (I'm not going to ask for the best setting of this variable, that's already in this thread: http://www.dovecot.org/list/dovecot/2008-October/034067.html) Greetings, -- Peter Orlowski
Re: [Dovecot] Password authentication and character set
18.11.2008 19:57, Timo Sirainen wrote: Ok, I see how this makes things problematic. One couldn't just encode it to UTF-8 anyway and do the comparison after that (provided there would be an option enabled)? You can encode everything to UTF-8, but the result will be different depending on what the source character set is. If by "option" you mean that you'd have a single setting that specifies which the "non-utf8 charset" is that (hopefully) all your users are using, then sure that would be the a) choice in my previous reply. Yes, you're right. I suppose didn't think that through. So basically a password containing any non 7-bit ASCII is only "correct" when provided by a client using the same charset as the password is stored in... If the RFC states that the password should be provided as 7-bit ASCII then I think I'll google for a reason why some clients send the password as something else. Most client programmers haven't even thought about the whole issue. The password is typically 7bit. So they just send the password using whatever charset that the OS by default happens to use. In your case you're most likely not really seeing ISO-8859-1 charset, but rather Windows-1252. Although Windows-1252 is a superset of ISO-8859-1, but things like euro character is present in 1252 but not in 8859-1 (and euro in a different position in 8859-15). Yes, I see. So in light of this and the conversation on the imap-protocol -list http://mailman2.u.washington.edu/pipermail/imap-protocol/2008-February/000822.html our current options seem to boil down to having the passwords ISO-8859-1 encoded (given the demographics of our users). Those using operating systems with native UTF-8 clients have to use passwords containing only 7-bit characters. I didn't realise the specifications were so flexible on this password issue. Chears, Fredrik
Re: [Dovecot] Password authentication and character set
On Tue, 2008-11-18 at 19:27 +0200, Fredrik Grönqvist wrote: > 18.11.2008 19:03, Timo Sirainen wrote: > > On Tue, 2008-11-18 at 17:26 +0100, Geert Hendrickx wrote: > > > >> On Tue, Nov 18, 2008 at 05:51:05PM +0200, Timo Sirainen wrote: > >> > >>> On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote: > >>> > >>> > Is there a setting that "forces" the authentication daemon to > convert the provided password to a specific charset before the > comparison takes place, or how should one handle this? > > >>> Dovecot doesn't know the character set that the client is using, so it > >>> can't do charset conversion reliably. So the possibilities would be: > >>> > >> It seems like this is a limitation in the IMAP protocol. From RFC 3501: > >> > > > > I remember reading something about using UTF-8 and stringprep in > > authentication strings, probably some SASL spec or something. Dovecot > > should implement it some day.. But that won't help in any way if the > > client doesn't send the password as UTF-8. > > > > > Ok, I see how this makes things problematic. One couldn't just encode it > to UTF-8 anyway and do the comparison after that (provided there would > be an option enabled)? You can encode everything to UTF-8, but the result will be different depending on what the source character set is. If by "option" you mean that you'd have a single setting that specifies which the "non-utf8 charset" is that (hopefully) all your users are using, then sure that would be the a) choice in my previous reply. > So basically a password containing any non 7-bit ASCII is only "correct" > when provided by a client using the same charset as the password is > stored in... > If the RFC states that the password should be provided as 7-bit ASCII > then I think I'll google for a reason why some clients send the password > as something else. Most client programmers haven't even thought about the whole issue. The password is typically 7bit. So they just send the password using whatever charset that the OS by default happens to use. In your case you're most likely not really seeing ISO-8859-1 charset, but rather Windows-1252. Although Windows-1252 is a superset of ISO-8859-1, but things like euro character is present in 1252 but not in 8859-1 (and euro in a different position in 8859-15). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Password authentication and character set
On Tue, Nov 18, 2008 at 07:03:04PM +0200, Timo Sirainen wrote: > On Tue, 2008-11-18 at 17:26 +0100, Geert Hendrickx wrote: > > It seems like this is a limitation in the IMAP protocol. From RFC 3501: > > I remember reading something about using UTF-8 and stringprep in > authentication strings, probably some SASL spec or something. Dovecot > should implement it some day.. But that won't help in any way if the > client doesn't send the password as UTF-8. There has recently been a discussion about this on the imap-protocol mailing list: http://mailman2.u.washington.edu/pipermail/imap-protocol/2008-February/thread.html (they talk about LOGIN as well) Geert
Re: [Dovecot] Password authentication and character set
18.11.2008 19:03, Timo Sirainen wrote: On Tue, 2008-11-18 at 17:26 +0100, Geert Hendrickx wrote: On Tue, Nov 18, 2008 at 05:51:05PM +0200, Timo Sirainen wrote: On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote: Is there a setting that "forces" the authentication daemon to convert the provided password to a specific charset before the comparison takes place, or how should one handle this? Dovecot doesn't know the character set that the client is using, so it can't do charset conversion reliably. So the possibilities would be: It seems like this is a limitation in the IMAP protocol. From RFC 3501: I remember reading something about using UTF-8 and stringprep in authentication strings, probably some SASL spec or something. Dovecot should implement it some day.. But that won't help in any way if the client doesn't send the password as UTF-8. Ok, I see how this makes things problematic. One couldn't just encode it to UTF-8 anyway and do the comparison after that (provided there would be an option enabled)? So basically a password containing any non 7-bit ASCII is only "correct" when provided by a client using the same charset as the password is stored in... If the RFC states that the password should be provided as 7-bit ASCII then I think I'll google for a reason why some clients send the password as something else. Chears, Fredrik -- Fredrik Grönqvist
Re: [Dovecot] Password authentication and character set
On Tue, 2008-11-18 at 17:26 +0100, Geert Hendrickx wrote: > On Tue, Nov 18, 2008 at 05:51:05PM +0200, Timo Sirainen wrote: > > On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote: > > > > >Is there a setting that "forces" the authentication daemon to > > >convert the provided password to a specific charset before the > > >comparison takes place, or how should one handle this? > > > > Dovecot doesn't know the character set that the client is using, so it > > can't do charset conversion reliably. So the possibilities would be: > > It seems like this is a limitation in the IMAP protocol. From RFC 3501: I remember reading something about using UTF-8 and stringprep in authentication strings, probably some SASL spec or something. Dovecot should implement it some day.. But that won't help in any way if the client doesn't send the password as UTF-8. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Password authentication and character set
On Tue, Nov 18, 2008 at 05:51:05PM +0200, Timo Sirainen wrote: > On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote: > > >Is there a setting that "forces" the authentication daemon to > >convert the provided password to a specific charset before the > >comparison takes place, or how should one handle this? > > Dovecot doesn't know the character set that the client is using, so it > can't do charset conversion reliably. So the possibilities would be: > > a) UTF-8 vs. another 8bit charset can be detected pretty well by > checking if the input string is valid UTF-8 or not. So there could be > a setting to specify the fallback charset. > > b) Just brute force through all the configured charsets and test the > password against all of them. > > I don't really like either solution and I don't have much interest in > coding those myself. Feel free to do it yourself though, I might even > accept patches. :) > It seems like this is a limitation in the IMAP protocol. From RFC 3501: Characters are 7-bit US-ASCII unless otherwise specified. Other character sets are indicated using a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. CHARSETs have important additional semantics in addition to defining character set; refer to these documents for more detail. The SEARCH command has this optional CHARSET flag (to search in messages in non-ascii charsets) but it seems like the LOGIN command should accept only 7-bit ASCII arguments... Geert
Re: [Dovecot] pam_start() failed: system error
On Tue, 2008-11-18 at 16:02 +0100, Peter Orlowski wrote: > dovecot runs fine for 3-10 days, then people can't connect any > more, and dovecot says: > > Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact > LDAP server Set to nonzero: # Number of auth requests to handle before destroying the process. This may # be useful if PAM plugins leak memory. #auth_worker_max_request_count = 0 > I have tried different settings for worker_max_count, This only changes the max. number of worker processes, on a non-loaded server changing it does practically nothing. > and I had blocking=no in the passdb config v1.1 no longer has blocking=no. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] MESSAGE Quota not RFC2087 compliant
On Tue, 2008-11-18 at 15:36 +0100, Braun, Martin wrote: > RFC2087 (http://www.faqs.org/rfcs/rfc2087.html) describes the response like > as: > > STORAGE: Sum of messages' RFC822.SIZE, in units of 1024 octets BTW. Dovecot doesn't do this. Originally I kept wondering if it should be counting the RFC822.SIZEs or physical message sizes and then I ended up using physical sizes. But I guess it doesn't really matter. > MESSAGE: Number of messages > > As you can see, the response "MESSAGES" differs from the specified "MESSAGE" > which leads to parsing issues on RFC compliant IMAP client implementations. > Using *:message=1337 throws a configuration error on Dovecot startup. I guess message quota is rarely used, since no-one has noticed this before. :) Fixed now: http://hg.dovecot.org/dovecot-1.1/rev/568fed966ca3 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Password authentication and character set
On Nov 18, 2008, at 5:32 PM, Fredrik Grönqvist wrote: Is there a setting that "forces" the authentication daemon to convert the provided password to a specific charset before the comparison takes place, or how should one handle this? Dovecot doesn't know the character set that the client is using, so it can't do charset conversion reliably. So the possibilities would be: a) UTF-8 vs. another 8bit charset can be detected pretty well by checking if the input string is valid UTF-8 or not. So there could be a setting to specify the fallback charset. b) Just brute force through all the configured charsets and test the password against all of them. I don't really like either solution and I don't have much interest in coding those myself. Feel free to do it yourself though, I might even accept patches. :) PGP.sig Description: This is a digitally signed message part
[Dovecot] Password authentication and character set
Hi, I've searched in the wiki and in the mailinglist archives but haven't found anything about password character sets within the dovecot authentication deamon. My problem is that we have users with passwords containing scandinavian characters (äöå, umlauts) and the debug log shows that different clients send the password in different charsets. The passwords are stored in a Mysql table, if that makes any difference. Outlook Express with LATIN 1 (ISO-8859-1): Nov 18 16:56:39 resilar dovecot: auth-worker(default): sql(fgr-1,193.64.206.190): Password mismatch Nov 18 16:56:39 resilar dovecot: auth-worker(default): sql(fgr-1,193.64.206.190): MD5(kksi) != '$1$xMPPHRdL$I0mrlPi5FMtwauSf20vjz0' MacMail UTF8: Nov 18 17:23:37 resilar dovecot: auth-worker(default): sql(fgr-1,193.64.206.190): Password mismatch Nov 18 17:23:37 resilar dovecot: auth-worker(default): sql(fgr-1,193.64.206.190): MD5(ääkkösiä12) != '$1$xMPPHRdL$I0mrlPi5FMtwauSf20vjz0' Is there a setting that "forces" the authentication daemon to convert the provided password to a specific charset before the comparison takes place, or how should one handle this? dovecot -n # 1.1.4: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s managesieve ssl_cert_file: /etc/ssl/certs/mail.crt ssl_key_file: /etc/ssl/private/mail.key ssl_cipher_list: ALL:!LOW disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_executable(managesieve): /usr/lib/dovecot/managesieve-login login_greeting: mail ready. login_process_per_connection: no mail_privileged_group: mail mail_location: maildir:~/mail mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_executable(managesieve): /usr/lib/dovecot/managesieve mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota mail_plugins(pop3): quota mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 mail_plugin_dir(managesieve): /usr/lib/dovecot/modules/managesieve imap_client_workarounds(default): delay-newmail outlook-idle imap_client_workarounds(imap): delay-newmail outlook-idle imap_client_workarounds(pop3): imap_client_workarounds(managesieve): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh pop3_client_workarounds(managesieve): sieve_storage(default): sieve_storage(imap): sieve_storage(pop3): sieve_storage(managesieve): ~/ sieve(default): sieve(imap): sieve(pop3): sieve(managesieve): ~/.dovecot.sieve auth default: mechanisms: plain login username_chars: [EMAIL PROTECTED] verbose: yes debug: yes debug_passwords: yes worker_max_count: 50 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: prefetch userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail plugin: quota: maildir Chears Fredrik -- Fredrik Grönqvist
[Dovecot] pam_start() failed: system error
Hi, I'm using dovecot 1.1.3 on FreeBSD 6.3, x86, files are on NFS, except control and index files, which are local, on UFS2. It's moderately loaded, there are usually not more than 30 clients simultaneously. dovecot runs fine for 3-10 days, then people can't connect any more, and dovecot says: Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact LDAP server Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: reconnecting to LDAP server... Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact LDAP server Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact LDAP server Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact LDAP server Nov 18 13:21:46 dizzy dovecot: auth-worker(default): pam(,xxx.xxx.xxx.xxx): pam_start() failed: system error Nov 18 13:21:46 dizzy dovecot-auth: in openpam_load_module(): no pam_permit.so found Nov 18 13:22:12 dizzy dovecot-auth: in openpam_load_module(): no pam_login_access.so found Nov 18 13:22:31 dizzy dovecot-auth: in openpam_load_module(): no pam_unix.so found Nov 18 13:22:42 dizzy dovecot-auth: in openpam_load_module(): no /usr/local/lib/pam_ldap.so found After restarting dovecot things are back to normal. I have tried different settings for worker_max_count, and I had blocking=no in the passdb config until a few day ago; changing that didn't help either. Here's my current config: # 1.1.3: /usr/local/etc/dovecot.conf protocols: imaps pop3s ssl_cert_file: /etc/ssl/certs/mailitp-chain.pem ssl_key_file: /etc/ssl/certs/mailkey2.pem login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login verbose_proctitle: yes first_valid_gid: 0 mail_privileged_group: mail mail_location: mbox:~/mail/:INDEX=/srv/dovecot/indexes/%u.oldmail:INBOX=/var/mail/%u mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugins(default): zlib mail_plugins(imap): zlib mail_plugins(pop3): mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh namespace: type: private separator: / prefix: NEWmail/ location: maildir:~/Maildir/:INDEX=/srv/dovecot/indexes/%u:CONTROL=/srv/dovecot/control/%u list: yes subscriptions: yes namespace: type: private separator: / location: mbox:~/mail/:INBOX=/var/mail/%u:INDEX=/srv/dovecot/indexes/%u.oldmail:CONTROL=/srv/dovecot/control/%u.oldmail inbox: yes list: yes subscriptions: yes auth default: worker_max_count: 20 passdb: driver: pam args: blocking=yes userdb: driver: passwd Greetings, -- Peter Orlowski
[Dovecot] MESSAGE Quota not RFC2087 compliant
Hi, the configuration of my Dovecot 1.1.3 quota plugin looks like this: quota_rule = *:storage=1G quota_rule2 = *:messages=1337 this leads to the following GETQUOTAROOT response: 01 GETQUOTAROOT INBOX * QUOTAROOT "INBOX" "mbraun quota" * QUOTA "mbraun quota" (STORAGE 6553 1048576 MESSAGES 122 1337) 01 OK Getquotaroot completed. RFC2087 (http://www.faqs.org/rfcs/rfc2087.html) describes the response like as: STORAGE: Sum of messages' RFC822.SIZE, in units of 1024 octets MESSAGE: Number of messages As you can see, the response "MESSAGES" differs from the specified "MESSAGE" which leads to parsing issues on RFC compliant IMAP client implementations. Using *:message=1337 throws a configuration error on Dovecot startup. dovecot-1.1.6/src/plugins/quota/quota.h /* Number of messages. */ #define QUOTA_NAME_MESSAGES "MESSAGES" Greetings, MartinBEGIN:VCARD VERSION:2.1 FN:Braun, Martin N:Braun;Martin;;; BDAY:19850227 ADR;TYPE=work;QUOTED-PRINTABLE:;;Martinstra=C3=9Fe 41;Olpe;NRW;57462;DE ADR;TYPE=home:;;Ostlandstr. 15;Siegen;NRW;57080;Germany TEL;TYPE=work;TYPE=voice:+49 (2761) 8385-17 TEL;TYPE=home;TYPE=voice:+49 (271) 2338434 TEL;TYPE=cell;TYPE=voice:+49 171 6420266 TEL;TYPE=cell;TYPE=voice:0171 6420266 EMAIL:[EMAIL PROTECTED] EMAIL:[EMAIL PROTECTED] ORG:Open-Xchange GmbH;Quality Assurance NOTE;QUOTED-PRINTABLE:Quality Assurance Department. OX5/OX6/OXtenders, GUI/= Server/Interfaces/Admin Tests, Test automatization,=20 REV:20080821T111045.917Z UID:[EMAIL PROTECTED] END:VCARD
