August 2006 - dovecot

[Dovecot] Password mismatch - SHA1 authentication problem.
by guard 09 Oct '06

09 Oct '06

Hello, I have problem with authentication. I'm using SHA1 passwords stored in MySQL. >From debug: Info: auth-worker(default): sql(test@mail, IP): query: SELECT password FROM vmail WHERE mail = 'test@mail' Info: auth-worker(default): sql(test@mail ,IP): Password mismatch Info: auth-worker(default): sql(test@mail ,IP): SHA1(dupadupa) != '2bca9dbe8a14811c687bb8c51c0e1cd14db8a018' I tried convert password to upper case, but it didn't help. Then I tried authentication in plain text and everything works fine... So, does dovecot crypt SHA1 using other method? I also use same SHA1 passwords to authenticate users in exim and it doesn't have any problem with that. I'm using mysql 5.0.24 and dovecot 1.0 rc7. Best regards, Tomasz Krynicki

2 1

[Dovecot] OT: NIS Authentication
by Jeff Graves 04 Sep '06

04 Sep '06

Ran into a major issue with my setup overnight: We have a Win2K AD domain running SFU with a master and 1 slave NIS server. Our mail server is a FC1 box that runs dovecot and a MailScanner/sendmail config. The mail server is configured as a NIS client. The problem is that we lost power overnight and all of the boxes shutdown after the UPS's ran out of battery. After the power came back on, all of the boxes automatically rebooted. The problem is that our mail server is somewhat faster than the rest of the servers. It booted up before the master or slave NIS servers were up and running. Since the mail server uses a PAM NIS authentication scheme, it knows nothing about our users unless it connects to a NIS server. So, this morning users were getting "unknown username" type errors with outlook. Furthermore, the mail logs show that sendmail was rejecting mail with "unknown user" errors. It wasn't until we rebooted the mail server and it was able to reconnect to the NIS servers that mail resumed being received and users could access it. It seems like a fundamental problem with our setup. Since I'll eventually be updating the box to a newer OS and configuration, I need to plug this hole somehow without changing the authentication scheme. Furthermore, I'm concerned that if the master or slave went down while the mail server was still up, we'd see similar results. I'm thinking of one of two options to fix this but wanted to run it by everyone to see if there was a better way: 1) Configure the boot loader to wait 5 minutes before loading the OS (it uses GRUB so I'll set it display the OS menu screen for 5 minutes and then boot). Then if I'm doing maintenance to the box I can just hit enter to boot immediately and hopefully the 5 minute delay will allow the other boxes to boot after a power outage. This won't cover me if it's not a power outage (Eg. The master or slave dies). 2) Configure the mail server as an NIS slave. I'm thinking that this will basically "copy" the user info (username, password, homedir, etc.) on a schedule and store it locally on the mail server (is this how it works?). This covers both issues - power outage and a server dying. But I've read about problems getting password sync to happen quickly. I'd ideally like it to happen immediately (without any manual intervention) but I don't think this is possible. Thoughts? Jeff Graves, MCSA Customer Support Engineer Image Source, Inc. 10 Mill Street Bellingham, MA 02019 508.966.5200 - Phone 508.966.5170 - Fax jeff(a)image-src.com - Email www.image-src.com

5 4

[Dovecot] SPA (NTLM) Authentication
by Neil Briscoe 03 Sep '06

03 Sep '06

Hello I have just spent a happy day (!) configuring Exim4 to accept authenticated connections from full blown Outlook clients. That works. Unfortunately, by ticking the "Use SPA" box in Outlook it now demands SPA on the POP3 server as well. The existing POP3 server doesn't support this style of authentication. I believe Dovecot will. We're already using it as an IMAP server. What I'm worried about is diverting its current view from /etc/passwd. I have an /etc/exim4/passwd file which contains three fields for the users tested so far, their name, an encrypted password, and a clear text one. Timo has already told me that the system needs access to the cleartext password (or an NTLM style password) in order to work. It would be nice if I could have the system check the /etc/exim4/passwd file and if the user wasn't there then check the /etc/passwd file - and ignore NTLM as it would normally. Regards Neil -- Neil Briscoe Adelix Ltd neil.briscoe(a)adelix.com web: www.adelix.com tel: 0845 230 9592 / fax: 0845 230 9591 / main office: 0845 230 9590 snail: The Old Post Office, Bristol Rd, Hambrook, Bristol BS16 1RY. UK. skype: stonefish001 Adelix Ltd is BS EN ISO 9001:2000 Certified (No. GB 12763) Any views expressed in this email communication are those of the individual sender, except where the sender specifically states them to be the views of a member of Adelix Ltd. Adelix Ltd. does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors or interference. ------------------------------------------------------------------------------------ Scanned for viruses, spam and offensive content by CensorNet MailSafe Professional Web & E-mail Filtering from www.censornet.com

1 1

[Dovecot] DIGEST-MD5 doesn't work
by Jürgen Herz 01 Sep '06

01 Sep '06

Hi, my dovecot installation works since months and clients authenticate using CRAM-MD5. But today I got the first chance to test an client that supports DIGEST-MD5 - and it doesn't work. Because of lack of other supporting clients and servers I'm now at the point I don't know which side is to blame. The error I get after the client answers the servers challenge is "-ERR Authentication failed: Missing nonce parameter". Though I don't know how DIGEST-MD5 works I wonder about the message because the clients answer contains a nonce parameter (captured with tcpdump): YXV0aHppZD0ib3RycyIsY2hhcnNldD11dGYtOCxjbm9uY2U9IjFlOTZkYmZiZWEwZjUxNmVhZjEyYmM0NjU1M2JmZjVlIixkaWdlc3QtdXJpPSJwb3AzL25hbm8iLG5jPTAwMDAwMDAxLG5vbmNlPSJPVGpGWmhjS2FIVjZSVGMyZlRDTXJ3PT0iLHFvcD1hdXRoLHJlYWxtPSIiLHJlc3BvbnNlPTVmMTQyZWVlN2FmMWVmYTJhYWI5ZmM0ODNiOGJjOTJhLHVzZXJuYW1lPSJvdHJzIg== authzid="otrs",charset=utf-8,cnonce="1e96dbfbea0f516eaf12bc46553bff5e", digest-uri="pop3/nano",nc=00000001,nonce="OTjFZhcKaHV6RTc2fTCMrw==", qop=auth,realm="",response=5f142eee7af1efa2aab9fc483b8bc92a,username="otrs" Client is a Perl script using Net::POP3 and Authen::SASL Modules Dovecot is version 0.99.14 - I know it's old and not supported. If one tells me the bug is known and fixed in 1.0rc, then I'll think about upgrading, but I just to test I don't want to change my running system. Regards, Jürgen

1 1

[Dovecot] deliver LDA and INBOX location
by David Lee 01 Sep '06

01 Sep '06

(OS: Fedora Core 5; dovecot: 1.0 rc7) On a typical UNIX-like OS, the INBOXes are in "/var/spool/mail/" using the user identifier: so user 'fred' has INBOX "/var/spool/mail/fred". We have a well-established different convention which subdivides this, based on the last two digits of the uid: "/var/spool/mail/12/fred" (for fred's uid as something ending "[...]12"). This is working nicely with dovecot, using the new rc7 functionality: default_mail_env = mbox:%h:INBOX=/var/spool/mail/%-2.02i/%u:[...] I am now trying to get sendmail to use dovecot's "deliver" as the LDA, (following "http://wiki.dovecot.org/LDA") as a simple drop-in replacement for the normal LDA. (Actually our migration starting point is a UW-IMAP background using its 'tmail' as LDA.) 1. It seems that using "auth default {...socket listen {...}...}" is mandatory. Can someone confirm? This feels like an extra complication: is it strictly necessary in a NIS/PAM set-up? (Fair enough if so.) 2. The main problem is that, according to the log file, the delivery attempt is being made to an INBOX "/var/spool/mail//fred". That is, it seems to be ignoring the "default_mail_env" setting. Have I missed something in the wiki, or is this a bug of some sort? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

1 1

[Dovecot] No tcp wrappers, other ideas to help stop brute force attacks?
by David Rees 01 Sep '06

01 Sep '06

I'm looking for a way to deny access to dovecot from certain IP addresses, basically to help prevent brute force attacks on the server. Right now I'm using denyhosts which scans /var/log/secure for authentication failures which then can add an entry to /etc/hosts.deny, but since dovecot doesn't have tcp wrappers support, that doesn't do anything. It doesn't look like I can run dovecot run xinetd. Any other ideas to help protect dovecot from brute force attacks? I don't think pam can help, can it? Otherwise I need to figure out a way to have denyhosts trigger iptables rules or something, or maybe there's another application that will work? -Dave

9 15

[Dovecot] one example, just one example ...
by OpenMacNews 01 Sep '06

01 Sep '06

... of a correctly formatted QUOTA spec in/for a static userdb. That's all I'm askin' for! i've tried a bunch of variants. the most recent two: user@domain.com:{PLAIN}testpass:::::: quota=maildir:storage=4096 user@domain.com:{PLAIN}testpass:::::: maildir:storage=4096 *none* (so far ...) work to override the spec in dovecot.conf. no errors in the logs; rather, simply: dovecot: Aug 31 08:54:25 Info: auth(default): passwd-file /var/MailServer/Data/USERS/imap_user_file: Read 2 users nobody? really, nobody does this successfully? richard

2 2

[Dovecot] [Fwd: dovecot-1.0_rc7 crashes (Login process died too early) with repeated deletes from thunderbird]
by Tim Schafer 01 Sep '06

01 Sep '06

I've run this test on every permutation of poll and notify: can NOT reproduce the crash: --with-ioloop=select --with-notify=none --with-ioloop=select --with-notify=dnotify --with-ioloop=select --with-notify=inotify --with-ioloop=poll --with-notify=none --with-ioloop=poll --with-notify=dnotify --with-ioloop=poll --with-notify=inotify CAN reproduce the crash: --with-ioloop=epoll --with-notify=none --with-ioloop=epoll --with-notify=dnotify --with-ioloop=epoll --with-notify=inotify So it would seem that epoll is related some how. As IDLE only seems to work well with epoll, I'm highly interested in resolving this crash. My Linux kernel is version 2.6.14.2 glibc 2.3.6 If any other info would help, please let me know. If any other test combinations would be helpful, I will try to do them ASAP. Regards, Tim Schafer -------- Original Message -------- Subject: [Dovecot] dovecot-1.0_rc7 crashes (Login process died too early) with repeated deletes from thunderbird Date: Thu, 24 Aug 2006 15:18:56 -0700 From: Tim Schafer <tim_schafer(a)shipfsp.com> To: Dovecot Mailing List <dovecot(a)dovecot.org> I can consistently reproduce a crash in dovecot: Select 20 or more messages and copy them to a test folder. Go into that test folder and SHIFT-DEL the messages rapidly (holding down SHIFT-DEL works best) Just rapidly DELing them (even holding down DEL) doesn't do it (unless it's the Trash folder) I'm using the following namespace (in case that's relevant) namespace private { separator = . prefix = INBOX. inbox = yes } The /var/log/syslog for the session reads: Aug 24 14:58:54 hostname dovecot: Dovecot v1.0.rc7 starting up Aug 24 14:58:55 hostname slapd[7243]: conn=147 fd=9 ACCEPT from IP=127.0.0.1:41074 (IP=0.0.0.0:389) Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 BIND dn="" method=128 Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 RESULT tag=97 err=0 text= Aug 24 14:59:09 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:09 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:09 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:09 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:09 hostname dovecot: auth(default): master in: REQUEST^I1^I10081^I1 Aug 24 14:59:09 hostname dovecot: auth(default): master out: USER^I1^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:09 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:10 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:10 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:10 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:10 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:10 hostname dovecot: auth(default): master in: REQUEST^I2^I10082^I1 Aug 24 14:59:10 hostname dovecot: auth(default): master out: USER^I2^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:10 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:12 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:12 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:12 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:12 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:12 hostname dovecot: auth(default): master in: REQUEST^I3^I10085^I1 Aug 24 14:59:12 hostname dovecot: auth(default): master out: USER^I3^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:12 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname dovecot: IMAP(username): Disconnected Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname last message repeated 2 times Aug 24 14:59:14 hostname dovecot: Login process died too early - shutting down Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname slapd[7243]: conn=147 op=1 UNBIND Aug 24 14:59:14 hostname slapd[7243]: conn=147 fd=9 closed -- Regards, Tim Schafer

1 1

[Dovecot] MANAGESIEVE patch v2
by Stephan Bosch 01 Sep '06

01 Sep '06

Hello Timo, Dispite the heat out here, I managed to come up with a new version of the managesieve patch for dovecot-1.0rc2: - Fixed the bug (missing CRLF) in the authenticate command - Modified the sieve storage library making the interface much less crude. - The scripts put on the server using the putscript command are now checked before they are accepted. - The reported SIEVE capability is now directly read from the sieve implementation (in this case cmu), listing much more than "FILEINTO VACATION". - Fixed some minor bugs in the putscript command Considering the dovecot-sieve plugin, I noticed that you obviously do not want to include the cmu sieve code in the main dovecot source tree. Unfortunately I did not see any other way but to include this library in my patch to make it support checking the uploaded scripts (for now). There are a few alternatives to solve this issue. We could combine de dovecot-sieve plugin with the managesieve patch yielding a single large sieve plugin. However, this would require some means to let the master know about the new managesieve process type. This could be achieved with some more plugin magic. Another way to solve this problem is by truly only excluding the cmu source from the main dovecot tree. If the interface of the sieve implementation is abstracted somehow, one could build a plugin interface for sieve implementations. This sieve interface would be common to dovecot-deliver and the managesieve daemon. This way, it does not matter how the sieve language is implemented (dovecot could even implement its own and still support cmu and others). I saw a hint to this solution in your original dovecot-lda plugin (i.e. sieve-mailutils.c etc), so you must have been playing with this idea as well. I took the liberty to define an example interface for the sieve implementations in the src/lib-sieve directory. It was concieved very quickly and it is far from complete, but it should support the current features of the delivery process. It is only tested for the managesieve putscript verification (no script was ever run though this interface). I am also not quite happy with the error reporting scheme of this interface. This needs more work and if you don't like it you can of course discard it entirely and define your own. Currently, I am also testing other sieve implementations. I am experimenting with libsieve2 (libsieve.sourceforge.net) and with building a wrapper around 'exim -bf'. This last solution is of course not useful for dovecot-lda, but I think the managesieve daemon is not only useful for dovecot itself. Support for these implementations is not yet included in this patch. The patch can be downloaded at: http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc2-MANAGESIEVE-v2.diff.gz (Simply apply it (-p0) to a clean 1.0rc2 source tree and run autogen.sh etc.) For testing, I have tried other client implementations than horde-ingo, but somehow everyone is very focused on the timsieve daemon and they tend to require its protocol specifics. The only other implementation I got working is smartsieve. The others either crashed or produced protocol errors (i.e. sieveshell). I hope I can get more client implementations to work to ensure the incompatibilies are not my fault. I am very eager to know what you think about the sieve implementation ideas and what you think of the new managesieve patch. Regards, -- Stephan Bosch stephan(a)rename-it.nl

2 1

[Dovecot] rc >= 6, libtool and zsh
by Thomas Hummel 31 Aug '06

31 Aug '06

Hello Timo, On FreeBSD 6.1-STABLE, rc7 doesn't build (rc6 didn't either) because of a broken "sed" in the genarated "libtool" script, at least with the "zsh" shell comming from the ports (zsh-4.3.2). This has occured starting from your move from Autoconf 2.59 to Autoconf 2.60 since for some reason, now "libtool" is run by zsh (instead of sh as in 2.59). I didn't investigate if it comes from : . "me/FreeBSD" : my particular version of zsh, or some patch that may be included in the port . "you" : changes in config.in, some problems in autotools you are using . "Debian" : the 1.5.22 Debian 1.5.22-4 patches of "ltmain.sh" used . "Libtool" : maybe some strange interaction with zsh . "Autoconf" : maybe some bug with the libtool script generation by configure . or some other reason At least, it works if I force CONFIG_SHELL to be /bin/sh -- Thomas Hummel | Institut Pasteur <hummel(a)pasteur.fr> | Pôle informatique - systèmes et réseau

1 0