Re: [Dovecot] Password authentication and character set
On Wed, Nov 19, 2008 at 08:44:21AM +0200, Fredrik Grönqvist wrote:
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.
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.
If you only have to support two or three different charsets, I think you could
use a clever MySQL passdb query to match either of them.
Have a look at http://wiki.dovecot.org/AuthDatabase/SQL under Password
verification by SQL server, and expand the password match to something like
(passwd = PASSWORD('%w') OR passwd = PASSWORD(CONVERT(_latin1'%w' USING utf8)))
assuming you store the passwords as UTF-8 and assume the input is either UTF-8
or ISO-8859-1.
Geert
Re: [Dovecot] Password authentication and character set
On Wed, Nov 19, 2008 at 01:54:48PM +0200, Fredrik Grönqvist wrote: Thanks for the info, a setup like this is what I opted for eventually. I added a note to that wiki page that the query also needs to return the nopassword -field for Dovecot 1.1+ to accept the NULL password: Ok, good catch (I hadn't actually tested the example). In case someone else is looking for info about this, this workaround works for DB backed accounts, as you mention, but will probably not work with an LDAP (or other) backend. Right, it's just a hack that fits your particular setup. :-) For a proper solution the IMAP specification would have to be updated to allow non-ASCII characters in logins/passwords, and apparantly they _are_ discussing that. But even if the IMAP protocol gets updated to allow it, this would also impact eg. POP3 and SMTP authentication which in many setups use the same passwords. And of course all IMAP (and other) client software (including webmails etc) would have to be adapted, too. Geert
Re: [Dovecot] Password authentication and character set
19.11.2008 14:33, Geert Hendrickx wrote: In case someone else is looking for info about this, this workaround works for DB backed accounts, as you mention, but will probably not work with an LDAP (or other) backend. Right, it's just a hack that fits your particular setup. :-) For a proper solution the IMAP specification would have to be updated to allow non-ASCII characters in logins/passwords, and apparantly they _are_ discussing that. But even if the IMAP protocol gets updated to allow it, this would also impact eg. POP3 and SMTP authentication which in many setups use the same passwords. And of course all IMAP (and other) client software (including webmails etc) would have to be adapted, too. Geert Yep, that would be the proper solution, and it's good that there is some progress towards this, but I'm not holding my breath for this to actually happen any time soon. The need for backwards compatibility will probably make the adoption a slow (and possibly painful) transition. Chears, Fredrik --
Re: [Dovecot] Password authentication and character set
19.11.2008 10:27, Geert Hendrickx wrote:
On Wed, Nov 19, 2008 at 08:44:21AM +0200, Fredrik Grönqvist wrote:
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.
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.
If you only have to support two or three different charsets, I think you could
use a clever MySQL passdb query to match either of them.
Have a look at http://wiki.dovecot.org/AuthDatabase/SQL under Password
verification by SQL server, and expand the password match to something like
(passwd = PASSWORD('%w') OR passwd = PASSWORD(CONVERT(_latin1'%w' USING utf8)))
assuming you store the passwords as UTF-8 and assume the input is either UTF-8
or ISO-8859-1.
Geert
Thanks for the info, a setup like this is what I opted for eventually. I
added a note to that wiki page that the query also needs to return the
nopassword -field for Dovecot 1.1+ to accept the NULL password:
# NOTE: '\' line splitting is used only for readability, currently
Dovecot doesn't support it
password_query = SELECT NULL AS password, 'nopassword', userid AS user \
FROM users WHERE userid = '%u' AND mysql_pass = password('%w')
In case someone else is looking for info about this, this workaround
works for DB backed accounts, as you mention, but will probably not work
with an LDAP (or other) backend.
Chears, Fredrik
--
Re: [Dovecot] Mail.app Subscriptions
On Sun, 2008-11-16 at 20:44 -0500, Neil wrote: I've noticed that when I go to Account Info in Mail.app, and then to the Subscription List tab, Mail.app will spin for a bit, and then give up, without showing any folders and all the buttons are grayed out. Does anyone know if this a Mail.app issue or a Dovecot issue, if there're any work-arounds, and/or if this is something I should be concerned about? It's a Mail.app issue. It doesn't really support subscriptions at all. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Bug in 1.1.4: New line required in ACL files
On Thu, 2008-11-13 at 16:38 +0100, [EMAIL PROTECTED] wrote: Hello, just wanted to notify you about a bug i found in 1.1.4 ACL handling: Global ACLs are ignored, when there is no line break (i.e. owner lr is ignored while owner lr\n works). I didn't track this down to see if the same happens for per-user ACLs, but it should be quite obvious in the source anyways. Most of the files Dovecot reads behave like this, so it was more or less intentional. But changed now: http://hg.dovecot.org/dovecot-1.1/rev/d94c516dfdd2 http://hg.dovecot.org/dovecot-1.1/rev/1d26ddce09e6 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] patch: list shared namespace
On Mon, 2008-11-03 at 13:03 +0100, Bernhard Herzog wrote: As you can see, the non-existing foo.foo isn't returned because its child foo.foo.foo also matches the pattern and is returned. But the non-existing foo.bar is returned because its children don't match the pattern. It took me forever to get all this stuff working right with Maildir++. :) I can imagine :). The reason it should work with ACLs more or less automatically is that when the mailbox list is populated by acl_mailbox_try_list_fast, it only adds the mailboxes that the user can see using mailbox_list_iter_update. mailbox_list_iter_update takes care of filling in the nonexisting parent mailboxes if necessary. That's not correct actually. acl_mailbox_try_list_fast adds all mailboxes that exist in dovecot-acl-list file, i.e. all mailboxes that have 'l' right set to someone (not necessarily to you). So if you have: foo: owner no rights foo/bar: user=xyz l Then foo should be visible as non-existing mailbox for user xyz, but no-one else. With your change it will be visible to everyone. Of course, assuming there's a reason acl_mailbox_try_list_fast has a try in its name and that it actually can fail, foo, foo.foo and foo.bar could perhaps end up in the mailbox list even if they do not have children that are visible to the user. The name implies that it could fail. But .. hmm. I'm not sure yet, have to look at the code some more. :) signature.asc Description: This is a digitally signed message part
[Dovecot] mail_privileged_group not working for dotlock files (1.1.6)
Hello, Running dovecot 1.1.6 on centOS 5 and RHEL 5. With the settings: pop3_lock_session = yes mail_privileged_group = mail mail_location = mbox:~/:INBOX=/var/spool/mail/%u mbox_read_locks = fcntl mbox_write_locks = dotlock fcntl and /var/spool/mail permissions: drwxrwx--x 2 root mail4096 Nov 19 10:16 mail/ Trying to connect via POP3 results in this error: --- Nov 19 09:31:01 lexiconn2 dovecot: child 32127 (pop3) killed with signal 11 Nov 19 09:31:01 lexiconn2 dovecot: POP3(cerberus): file_lock_dotlock() failed with mbox file /var/spool/mail/xxx: Permission denied Nov 19 09:31:01 lexiconn2 dovecot: pop3-login: Login: user=xxx, method=PLAIN, rip=1.2.3.4, lip=5.6.7.8, secured --- The docs seem to indicate the above config / settings should work. Is this a bug? The reason we have dotlock as the primary format is due to procmail LDA from sendmail: --- procmail -v 21|grep Locking Locking strategies: dotlocking, fcntl() --- I assume we have to make the mbox_write_locks match the procmail locking... Thanks. Rob
Re: [Dovecot] v1.1.6 released
Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign! Timo Sirainen wrote: http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig The invalid message address parsing bug is pretty important since it allows a remote user to send broken mail headers and prevent the recipient from accessing the mailbox afterwards, because the process will always just crash trying to parse the header. This is assuming that the IMAP client uses FETCH ENVELOPE command, not all do. Note that it doesn't affect versions older than v1.1.4. + dovecot -n and -a now prints some system information at the top. + More error/debug message logging improvements. - pop3-login: Fixed assert-crash if a client sent USER+PASS+USER+PASS commands in the same IP packet. - Parsing an invalid message address like From: ( caused an assert-crash in v1.1.4 and v1.1.5. - Folding whitespace wasn't handled correctly inside quoted-strings, causing some messages to be parsed incorrectly. - mbox: Fixed saving messages that begin with a valid From_-line.
Re: [Dovecot] patch: list shared namespace
All of this is now implemented. I think shared mailboxes/ACLs are now fully working. The only thing left is to avoid calling acl_lookup_dict_rebuild() after each ACL change, but rather just update the dict directly with the changes. Hmm. Wonder how quota behaves with shared mailboxes.. That's probably broken. On Sat, 2008-11-01 at 23:43 +0200, Timo Sirainen wrote: On Fri, 2008-10-31 at 17:51 +0200, Timo Sirainen wrote: LIST % - List foo as non-existing LIST foo - List foo as non-existing LIST * - List foo/bar only There are also some truly horrible cases. For example: 1 list foo* * LIST (\HasNoChildren) . foo.foo.foo * LIST (\HasNoChildren) . foo.bar.baz 1 ok 2 list f*o.% * LIST (\HasNoChildren) . foo.foo.foo * LIST (\Noselect \HasChildren) . foo.bar 2 OK List completed. 3 list f*r * LIST (\Noselect \HasChildren) . foo.bar 3 OK List completed. As you can see, the non-existing foo.foo isn't returned because its child foo.foo.foo also matches the pattern and is returned. But the non-existing foo.bar is returned because its children don't match the pattern. It took me forever to get all this stuff working right with Maildir++. :) I think it would be possible to implement the same somewhat easily in ACL code: 1. When ACL code sees that a non-existing mailbox is to be returned, find out if there are any patterns that match the mailbox and that ends with * character. If yes, don't return the mailbox (because its children will be returned anyway). If not: 2. Start a new mailbox listing that lists children of the non-existing mailbox (mailbox/*). If you find: a) A visible mailbox that matches the original patterns - don't return the original non-existing mailbox (since its child will be returned later) b) No visible mailboxes - don't return the original non-existing mailbox c) Fallback to returning the non-existing mailbox The same logic should also be used when determining if shared namespace prefixes should be returned (I think ACL code can do that too?) Also that code should work properly when mailbox names contain * or % characters. Basically it means that when generating the mailbox/* pattern replace all * chars with % chars in the mailbox name and then later when going through the results skip over everything that doesn't begin with the real mailbox name. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Solving CVE-2008-4870
On Thu, 2008-11-13 at 15:57 +0200, Timo Sirainen wrote: On Nov 13, 2008, at 1:03 PM, Michal Hlavinka wrote: Hi, we're trying to solve CVE-2008-4870 = rhbz#436287 = dovecot.conf is world readable - possible password exposure. This problem seems to be little more complicated than we thought. dovecot.conf can contain passphrase for ssl key, which is available for everyone since dovecot.conf has world readable permissions. Maybe a new separate dovecot-secret.conf? When Dovecot starts up it first reads dovecot.conf and after that dovecot-secret.conf. deliver wouldn't read dovecot-secret.conf at all. Added !include and !include_try: http://hg.dovecot.org/dovecot-1.1/rev/5f471f5b06d2 http://hg.dovecot.org/dovecot-1.1/rev/313d1195318f deliver will currently just skip !include_try lines and gives an error if !include is tried to be used. So for now it's not a good idea to start using !include in default settings. :) signature.asc Description: This is a digitally signed message part
[Dovecot] CRAM-MD5 and proxy_maybe
When using proxy_maybe CRAM-MD5 authentication fails when the connection is proxied. Is this expected behavior? Is proxy_maybe too simplified for this case? We're using SQL so I could rewrite the query with IFs to fake proxy_maybe and return the password as NULL and nologin as Y, but if it works that way couldn't it work with proxy_maybe? This works: password_query = \ SELECT NULL AS password, host, CONCAT(user,'@',domain) AS destuser \ 'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy \ FROM accounts WHERE class='pop' AND domain='%d' This doesn't work if proxied and CRAM-MD5 auth: password_query = \ SELECT \ CONCAT(user,'@',domain) AS user, password, \ host, 'Y' AS proxy_maybe, \ target AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \ FROM accounts WHERE \ class='pop' AND domain='%d' AND user='%n' \ LIMIT 1 Thanks, David
Re: [Dovecot] Unbreakable NFS locking issues...
Hi all,
I've got an isolated test environment set up now, and am trying to figure
out how to get the index files to populate. So far, I cannot seem to get
them to appear in the /usr/local/dovecot/indexes directory as referenced
below. Here is the sql string:
[EMAIL PROTECTED] /usr/local/etc]# grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location, 143 AS uid,
143 AS gid, concat('*:storage=', floor(quota*1024)) AS quota_rule FROM
mailbox WHERE username = '%u' AND active = '1'
[EMAIL PROTECTED] /usr/local/etc]#
I've got mail working more or less, however the indexes simply will not
appear in the path referenced above. My suspicion has been that this is
where my nfs locking problems are occurring, as the indexes are just not
getting populated. Any ideas? I gather that the cacheing done through the
mysql database is desirable as it would tend to speed things up quite a
bitany ideas on how to pass the index location through the string as
well? Or is this generally regarded as a negligible gain?
Thanks everyone.
-Rod
On Thu, Nov 13, 2008 at 10:22 AM, Rod Treweek [EMAIL PROTECTED] wrote:
I'm also noticing that the INDEX=/usr/local/mail/indexes/ path is
completely emptyshouldn't this get populated if the config is getting
read properly?
On Thu, Nov 13, 2008 at 9:24 AM, Rod Treweek [EMAIL PROTECTED] wrote:
Thanks for the response. I also forgot to mention that this is on FreeBSD
6.3. Not sure if that makes a difference.
On Wed, Nov 12, 2008 at 4:07 PM, Seth Mattinen [EMAIL PROTECTED]wrote:
Rod Treweek wrote:
Yeah, Sorry, still kind of figuring out list protocol. Thanks for the
responses.
I've not built this system, but I've inherited the responsibility of
maintaining it, so I'm still kind of trying to gradually learn about how
everything works together.
I think that the main things are:
fcntl; pretty sure that dotlock is what we should be using, however, I
was
under the impression that lockd would/could deal with the file locking
issues, if it were present on both client and server.
Maybe, maybe not. I'd try dotlock and see if it helps.
~Seth
[Dovecot] New message notification
Hi What is the best option to notify a user that a message has arrived? The intention is to write a script that connects to a jabber server and checks if the user is online, so then a message is sent to user notifying him that he has received a new message. The solution should be compatible with Sieve filtering, so the script should not be executed when the message is moved to the SPAM folder, or pass to the script an argument specifying the folder where the message has been saved. Regards and thanks in advance. Juan Asensio Sánchez - http://www.nutum.es
Re: [Dovecot] v1.1.6 released
On Nov 19 2008, Adam McDougall wrote: Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign! We're running 1.1.4 in production on one machine, and have tried 1.1.5. and 1.1.6 in our test environment... all three still sometimes have the next message unexpectedly lost error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list. Other clients see the message fine. Effective workarounds: 1. Delete index files. 2. Have the user use a client such as Pine to bounce the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a new message now, as it is rewritten to add the appropriate header fields. I sent in a bug report with dovecot -n output and etc a couple of weeks ago; that info still holds. -Brian Hayden University of Minnesota Timo Sirainen wrote: http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig The invalid message address parsing bug is pretty important since it allows a remote user to send broken mail headers and prevent the recipient from accessing the mailbox afterwards, because the process will always just crash trying to parse the header. This is assuming that the IMAP client uses FETCH ENVELOPE command, not all do. Note that it doesn't affect versions older than v1.1.4. + dovecot -n and -a now prints some system information at the top. + More error/debug message logging improvements. - pop3-login: Fixed assert-crash if a client sent USER+PASS+USER+PASS commands in the same IP packet. - Parsing an invalid message address like From: ( caused an assert-crash in v1.1.4 and v1.1.5. - Folding whitespace wasn't handled correctly inside quoted-strings, causing some messages to be parsed incorrectly. - mbox: Fixed saving messages that begin with a valid From_-line. -- Brian Hayden UMN OIT Internet Services
Re: [Dovecot] New message notification
Juan Asensio Sánchez schreef: Hi What is the best option to notify a user that a message has arrived? The intention is to write a script that connects to a jabber server and checks if the user is online, so then a message is sent to user notifying him that he has received a new message. The solution should be compatible with Sieve filtering, so the script should not be executed when the message is moved to the SPAM folder, or pass to the script an argument specifying the folder where the message has been saved. In an ideal world, the best option would be using the Sieve notify extension with the xmpp (jabber) notify method. The Sieve community is working on devising a new set of standards to achieve exactly what you describe: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-12.txt http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-09.txt However, although I am currently implementing support for notify/mailto in the new Sieve plugin (to match cmusieve), I have no specific plans to implement notify/xmpp in the near future. So, this is not directly of much use to you. Maybe if it turns out to be really easy, I'll build a plugin in my spare time. For now, indeed, you will for instance have to write some sort of wrapper script for deliver that sends notifications and duplicates some of the tests that Sieve already performs in order to prevent notifying SPAM messages. Alternatively, you could define a special (internal!) mail address in the SMTP server that calls your notification script as pipe transport. Then you can redirect messages from your Sieve script to that mail address (e.g. [EMAIL PROTECTED]) if you want to send notifications. Still not very pretty though and potentially insecure if you are not very careful. How to achieve this second alternative precisely is a bit beyond me, as I am not that experienced in setting up SMTP services. Regards, -- Stephan Bosch [EMAIL PROTECTED]
Re: [Dovecot] v1.1.6 released
On Nov 19, 2008, at 10:29 PM, Brian Hayden wrote: On Nov 19 2008, Adam McDougall wrote: Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign! We're running 1.1.4 in production on one machine, and have tried 1.1.5. and 1.1.6 in our test environment... all three still sometimes have the next message unexpectedly lost error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list. I've finally managed to reproduce this with my own mails a few days ago. Now I'd just need to figure out what exactly is causing it and fix it. Other clients see the message fine. Effective workarounds: 1. Delete index files. 2. Have the user use a client such as Pine to bounce the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a new message now, as it is rewritten to add the appropriate header fields. 3. Don't use mbox. :) Although I thought this error was transparent to users. I get it every few days and haven't really noticed any problems because of it. Wonder what Outlook sees that causes it to break. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] v1.1.6 released
On Nov 19 2008, Timo Sirainen wrote: 3. Don't use mbox. :) Heh! We're on that route, but there are a lot of complicating factors (including lots of users who have to be handled very delicately through a conversion). -- Brian Hayden UMN OIT Internet Services
Re: [Dovecot] Unbreakable NFS locking issues...
On Nov 19, 2008, at 9:01 PM, Rod Treweek wrote:
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/
mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=',
floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
The userdb_* fields here are used only if you're using prefetch userdb.
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as
home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location,
mail_location field is ignored. It's called mail, which you're also
returning without the :INDEX.
So I guess you're 1) not using prefetch userdb so the userdb_mail in
password_query doesn't get used and 2) the mail field without :INDEX
is used from user_query.
I've got mail working more or less, however the indexes simply will
not
appear in the path referenced above. My suspicion has been that this
is
where my nfs locking problems are occurring, as the indexes are
just not
getting populated. Any ideas? I gather that the cacheing done
through the
mysql database is desirable as it would tend to speed things up
quite a
bitany ideas on how to pass the index location through the
string as
well? Or is this generally regarded as a negligible gain?
What caching? I'm not really sure what you're asking here.
PGP.sig
Description: This is a digitally signed message part
Re: [Dovecot] CRAM-MD5 and proxy_maybe
On Nov 19, 2008, at 8:14 PM, David Jonas wrote: When using proxy_maybe CRAM-MD5 authentication fails when the connection is proxied. Is this expected behavior? Is proxy_maybe too simplified for this case? Fails how? We're using SQL so I could rewrite the query with IFs to fake proxy_maybe and return the password as NULL and nologin as Y, but if it works that way couldn't it work with proxy_maybe? This works: password_query = \ SELECT NULL AS password, host, CONCAT(user,'@',domain) AS destuser \ 'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy \ FROM accounts WHERE class='pop' AND domain='%d' So all servers are using this authentication? It works because it lets users log in using any password. This doesn't work if proxied and CRAM-MD5 auth: password_query = \ SELECT \ CONCAT(user,'@',domain) AS user, password, \ host, 'Y' AS proxy_maybe, \ target AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \ FROM accounts WHERE \ class='pop' AND domain='%d' AND user='%n' \ LIMIT 1 The problem is that Dovecot doesn't know the plaintext password for logging into the remote server. It can't be extracted from CRAM-MD5 authentication. Are you storing plaintext passwords in the password field? If so, you could return password as pass (as well as the password field itself). If you're not using plaintext passwords, you'll have to use a master password (see http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy) . (I suppose in theory Dovecot could also implement CRAM-MD5 client functionality and use the stored CRAM-MD5 hash to log into the remote server, but this wouldn't work with many other auth mechanisms, such as DIGEST-MD5, so I don't want waste time on coding a CRAM-MD5-only solution.) PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] CRAM-MD5 and proxy_maybe
Timo Sirainen wrote:
On Nov 19, 2008, at 8:14 PM, David Jonas wrote:
When using proxy_maybe CRAM-MD5 authentication fails when the connection
is proxied. Is this expected behavior? Is proxy_maybe too simplified for
this case?
Fails how?
We're using SQL so I could rewrite the query with IFs to fake
proxy_maybe and return the password as NULL and nologin as Y, but if it
works that way couldn't it work with proxy_maybe?
This works:
password_query = \
SELECT NULL AS password, host, CONCAT(user,'@',domain) AS destuser \
'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy \
FROM accounts WHERE class='pop' AND domain='%d'
So all servers are using this authentication? It works because it lets
users log in using any password.
This doesn't work if proxied and CRAM-MD5 auth:
password_query = \
SELECT \
CONCAT(user,'@',domain) AS user, password, \
host, 'Y' AS proxy_maybe, \
target AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \
FROM accounts
WHERE \
class='pop' AND domain='%d' AND user='%n' \
LIMIT 1
The problem is that Dovecot doesn't know the plaintext password for
logging into the remote server. It can't be extracted from CRAM-MD5
authentication. Are you storing plaintext passwords in the password
field? If so, you could return password as pass (as well as the
password field itself). If you're not using plaintext passwords,
you'll have to use a master password (see
http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy).
(I suppose in theory Dovecot could also implement CRAM-MD5 client
functionality and use the stored CRAM-MD5 hash to log into the remote
server, but this wouldn't work with many other auth mechanisms, such
as DIGEST-MD5, so I don't want waste time on coding a CRAM-MD5-only
solution.)
Thanks Timo. I've been playing with the query for the past few hours and
I have a workable solution which turns out to be what you suggested
(passing pass) since we have to store plaintext anyway. It took me
awhile to glean it from the docs. Thanks for the support. We really
appreciate it.
Here's our query, for posterity:
SELECT \
IF('%l' != host, host, NULL) AS host, \
IF('%l' != host, 'Y', NULL) AS proxy, \
IF('%l' != host, 'Y', NULL) AS nodelay, \
IF('%l' != host, 'Y', NULL) AS nologin, \
IF('%l' != host, [EMAIL PROTECTED], NULL) AS destuser, \
IF('%l' != host, password, NULL) AS pass, \
CONCAT(user,'@',domain) AS user, \
password, \
target AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \
FROM accounts
WHERE \
class='pop' AND domain='%d' AND user='%n' \
LIMIT 1
Re: [Dovecot] Unbreakable NFS locking issues...
Hi Timo,
Thanks Timo. This is great. I followed your instructions, and sure enough,
everything is working as expected now. Thank you very very much. One
question I have, What's the advantage of using prefetch? Is this a
considerable performance benefit, or is it just more or less another way to
do things? Thanks again.
-Rod
On Wed, Nov 19, 2008 at 4:54 PM, Timo Sirainen [EMAIL PROTECTED] wrote:
On Nov 19, 2008, at 9:01 PM, Rod Treweek wrote:
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as userdb_mail, 143 AS
userdb_uid, 143 AS userdb_gid, concat('*:storage=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
The userdb_* fields here are used only if you're using prefetch userdb.
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/',maildir,
':INDEX=/usr/local/dovecot/indexes/',maildir) as mail_location,
mail_location field is ignored. It's called mail, which you're also
returning without the :INDEX.
So I guess you're 1) not using prefetch userdb so the userdb_mail in
password_query doesn't get used and 2) the mail field without :INDEX is
used from user_query.
I've got mail working more or less, however the indexes simply will not
appear in the path referenced above. My suspicion has been that this is
where my nfs locking problems are occurring, as the indexes are just not
getting populated. Any ideas? I gather that the cacheing done through
the
mysql database is desirable as it would tend to speed things up quite a
bitany ideas on how to pass the index location through the string as
well? Or is this generally regarded as a negligible gain?
What caching? I'm not really sure what you're asking here.
Re: [Dovecot] Auth Issues - Urgent - Help!
Well, most of my issues are gone with adding auth cache. However, I am having an issue. Sometimes, even though cache incorrect passwords is disabled, new passwords do not work. It would seem that once a user logs in with one password successfully the cache does not automatically retry if the user tries a different passwords. I would think that the auth cache should check to see if the password changed on the ldap server if something other than the cached password is entered. Is this something wrong with my configuraiton, or the auth code itself? Thanks, Dave Quoting Timo Sirainen [EMAIL PROTECTED]: On Wed, 2008-10-08 at 08:01 -0400, David Cunningham wrote: After a few hours of running, I get tons of the following errors in my logs: dovecot: Oct 08 07:41:50 Error: auth(default): ldap([EMAIL PROTECTED],x.x.x.x): Request queue is full BTW. I improved this error message slightly to also tell how many seconds old data is in the queue. http://hg.dovecot.org/dovecot-1.1/rev/0329dc4df5ed I guess you're using auth binds? If you weren't, I think it wouldn't be possible to fill the queue.
