- dovecot - dovecot.org

Re: [PATCH] Fix typo in src/imap-urlauth/imap-urlauth-worker.c
by Jelmer Vernooij 01 Aug '14

01 Aug '14

On Sun, Jul 20, 2014 at 12:50:43AM +0200, Jelmer Vernooij wrote: > The attached trivial patch fixes a typo in src/imap-urlauth/imap-urlauth-worker.c. Ping? > diff -r fd0616d553b0 -r 6fabd9046558 src/imap-urlauth/imap-urlauth-worker.c > --- a/src/imap-urlauth/imap-urlauth-worker.c Fri Jul 11 16:49:35 2014 +0300 > +++ b/src/imap-urlauth/imap-urlauth-worker.c Sun Jul 20 00:29:35 2014 +0200 > @@ -478,7 +478,7 @@ > } > if (client_run_url(client) < 0) { > client_abort(client, > - "Session aborted: Fatal failure while transfering URL"); > + "Session aborted: Fatal failure while transferring URL"); > return 0; > } > }

1 0

Solr 4+ schema.xml?
by G H 31 Jul '14

31 Jul '14

Does anyone have a Solr 4+ compatible schema.xml for dovecot indexing? I am trying to test to see if regex-based FTS searching works through IMAP, but Solr 4.9.0 is throwing an error, "SolrException: undefined field text", on startup with the schema.xml included with Dovecot 2.2.9. Thanks. G H

2 2

Issue with exim and auth protocol
by Mildred Ki'Lya 31 Jul '14

31 Jul '14

Hi, I'm trying to set up exim (4.83) as a submission server, and need to set up the dovecot authentication in exim. I'm having an issue with that (documented at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756258>) The problem is that exim doesn't follow the handshake as described here: <http://wiki2.dovecot.org/Design/AuthProtocol>. The wiki page says that the client should start the handshake, but exim waits for the server to start and to receive the DONE command until it starts its own handshake. What I actually get is: exim connects to dovecot auth dovecot VERSION 1 1 dovecot SPID 48 And then, dovecot stops (I presume it waits for the client handshake, VERSION and CPID). Exim on its side waits for the DONE. This results in the SMTP connection by exim never replying to the AUTH PLAIN command. This is exim 4.80 (or 4.83) and dovecot 2.1.7. I have another server set up almost exactly the same (but with dovecot 2.1.17) where it does work. In that case, dovecot finishes the handshake before exim starts its handshake. It results in: exim connects to dovecot auth dovecot VERSION 1 1 dovecot MECH PLAIN plaintext dovecot SPID 10905 dovecot CUID 1 dovecot COOKIE d3861d29441f06d962490eab8549fd46 dovecot DONE exim VERSION 1 0 exim CPID 10619 exim AUTH 1 PLAIN service=smtp secured rip=82.247.184.53 lip=80.67.179.36 nologin resp=<base64 encoded string> I don't understand what could change the dovecot behaviour in that regard. Is there a solution that would only require modifying the configuration? Thank you, Mildred

3 6

Die Hütchen-Spiel Mafia wird das nicht gerne sehen. Diese Katze ist Profi!
by Michael Grimm 31 Jul '14

31 Jul '14

http://heftig.co/katze-mit-huetchen/

3 5

▶ Leopard Is Getting Relaxed big cat purrs - YouTube
by Michael Grimm 30 Jul '14

30 Jul '14

Whow! In einer Auffangstation für Wildtiere in den USA laut Spiegel.de http://www.youtube.com/watch?v=4BLoHyeevcU

1 0

dovecot-2-2-pigeonhole-92405f753f6a - 77e6a42bff9b
by Tamsy 30 Jul '14

30 Jul '14

Just a report to Stephan: I tried to compile two builds from the Mercurial: - dovecot-2-2-pigeonhole-92405f753f6a - dovecot-2-2-pigeonhole-77e6a42bff9b Both builds fail to compile with the same following error: ---------------- 8< ---------------- ../../src/lib-sieve-tool/.libs/libsieve-tool.a(sieve-tool.o): In function `sieve_tool_open_output_stream': /usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src/lib-sieve-tool/sieve-tool.c:518: undefined reference to `o_stream_create_fd_autoclose' ../../src/lib-sieve/.libs/libdovecot-sieve.so: undefined reference to `i_stream_create_fd_autoclose' collect2: ld returned 1 exit status make[3]: *** [sievec] Error 1 make[3]: Leaving directory `/usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src/sieve-tools' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b' make: *** [all] Error 2 Server OS: 2 servers, both running on Ubuntu 10.04 32 Bit Rgds Tamsy

4 5

PAM and YubiKeys
by Jack 29 Jul '14

29 Jul '14

Hi List, I am trying to get authentication to Dovecot with a Yubikey OTP. I have the PAM modules installed and can successfully authenticate to ssh with the Yubikey, so I am confident that the network level and Yubikey configuration is correct. I can also authenticate to Dovecot via PAM using a plain password, however when I try to use the Yubikey authentication with Dovecot things don't go well. Network monitoring reveals that the software does not even attempt to connect to the authentication servers. My Dovecot authentication is configured as follows :- passdb { driver = pam args = failure_show_msg=yes dovecot override_fields = proxy host=1.2.3.4 master=XXXXXX pass=XXXXXX } userdb { driver = passwd-file args = username_format=%u /etc/dovecot/users } The dovecot Pam config file is :- auth sufficient pam_yubico.so id=99999 key="xxxxxxxxxxx" authfile=/etc/yubikey_mappings debug @include common-auth @include common-account @include common-session When failing to authenticate with Dovecot, the PAM debug log shows :- [../pam_yubico.c:parse_cfg(761)] called. [../pam_yubico.c:parse_cfg(762)] flags 0 argc 4 [../pam_yubico.c:parse_cfg(764)] argv[0]=id=xxxxxx [../pam_yubico.c:parse_cfg(764)] argv[1]=key="xxxxxx" [../pam_yubico.c:parse_cfg(764)] argv[2]=authfile=/etc/yubikey_mappings [../pam_yubico.c:parse_cfg(764)] argv[3]=debug [../pam_yubico.c:parse_cfg(765)] id=xxxxxx [../pam_yubico.c:parse_cfg(766)] key="xxxxxxxxx" [../pam_yubico.c:parse_cfg(767)] debug=1 [../pam_yubico.c:parse_cfg(768)] alwaysok=0 [../pam_yubico.c:parse_cfg(769)] verbose_otp=0 [../pam_yubico.c:parse_cfg(770)] try_first_pass=0 [../pam_yubico.c:parse_cfg(771)] use_first_pass=0 [../pam_yubico.c:parse_cfg(772)] authfile=/etc/yubikey_mappings [../pam_yubico.c:parse_cfg(773)] ldapserver=(null) [../pam_yubico.c:parse_cfg(774)] ldap_uri=(null) [../pam_yubico.c:parse_cfg(775)] ldapdn=(null) [../pam_yubico.c:parse_cfg(776)] user_attr=(null) [../pam_yubico.c:parse_cfg(777)] yubi_attr=(null) [../pam_yubico.c:parse_cfg(778)] yubi_attr_prefix=(null) [../pam_yubico.c:parse_cfg(779)] url=(null) [../pam_yubico.c:parse_cfg(780)] capath=(null) [../pam_yubico.c:parse_cfg(781)] token_id_length=12 [../pam_yubico.c:parse_cfg(782)] mode=client [../pam_yubico.c:parse_cfg(783)] chalresp_path=(null) [../pam_yubico.c:pam_sm_authenticate(823)] get user returned: jack [../pam_yubico.c:pam_sm_authenticate(929)] conv returned 44 bytes [../pam_yubico.c:pam_sm_authenticate(947)] Skipping first 0 bytes. Length is 44, token_id set to 12 and token OTP always 32. [../pam_yubico.c:pam_sm_authenticate(954)] OTP: ccccccbcitfdueencldivbcjvghvikdtrnujbgubirru ID: ccccccbcitfd [../pam_yubico.c:pam_sm_authenticate(985)] ykclient return value (101): Could not parse server response [../pam_yubico.c:pam_sm_authenticate(1038)] done. [Authentication service cannot retrieve authentication info] A successful authentication (via ssh) looks like [../pam_yubico.c:parse_cfg(761)] called. [../pam_yubico.c:parse_cfg(762)] flags 1 argc 4 [../pam_yubico.c:parse_cfg(764)] argv[0]=id=xxxx [../pam_yubico.c:parse_cfg(764)] argv[1]=key="xxxxxxxxxxxxxxxxxx" [../pam_yubico.c:parse_cfg(764)] argv[2]=authfile=/etc/yubikey_mappings [../pam_yubico.c:parse_cfg(764)] argv[3]=debug [../pam_yubico.c:parse_cfg(765)] id=xxxxxx [../pam_yubico.c:parse_cfg(766)] key="xxxxxxxxxxxxxxxxxxx" [../pam_yubico.c:parse_cfg(767)] debug=1 [../pam_yubico.c:parse_cfg(768)] alwaysok=0 [../pam_yubico.c:parse_cfg(769)] verbose_otp=0 [../pam_yubico.c:parse_cfg(770)] try_first_pass=0 [../pam_yubico.c:parse_cfg(771)] use_first_pass=0 [../pam_yubico.c:parse_cfg(772)] authfile=/etc/yubikey_mappings [../pam_yubico.c:parse_cfg(773)] ldapserver=(null) [../pam_yubico.c:parse_cfg(774)] ldap_uri=(null) [../pam_yubico.c:parse_cfg(775)] ldapdn=(null) [../pam_yubico.c:parse_cfg(776)] user_attr=(null) [../pam_yubico.c:parse_cfg(777)] yubi_attr=(null) [../pam_yubico.c:parse_cfg(778)] yubi_attr_prefix=(null) [../pam_yubico.c:parse_cfg(779)] url=(null) [../pam_yubico.c:parse_cfg(780)] capath=(null) [../pam_yubico.c:parse_cfg(781)] token_id_length=12 [../pam_yubico.c:parse_cfg(782)] mode=client [../pam_yubico.c:parse_cfg(783)] chalresp_path=(null) [../pam_yubico.c:pam_sm_authenticate(823)] get user returned: jack [../pam_yubico.c:pam_sm_authenticate(929)] conv returned 44 bytes [../pam_yubico.c:pam_sm_authenticate(947)] Skipping first 0 bytes. Length is 44, token_id set to 12 and token OTP always 32. [../pam_yubico.c:pam_sm_authenticate(954)] OTP: ccccccbcitfdetdfkbjrtfbuhgbtjgethkdebcgthgde ID: ccccccbcitfd [../pam_yubico.c:pam_sm_authenticate(985)] ykclient return value (0): Success [../pam_yubico.c:authorize_user_token(221)] Using system-wide auth_file /etc/yubikey_mappings [../pam_yubico.c:check_user_token(178)] Authorization line: jack:ccccccbcitfd [../pam_yubico.c:check_user_token(182)] Matched user: jack [../pam_yubico.c:check_user_token(187)] Authorization token: ccccccbcitfd [../pam_yubico.c:check_user_token(190)] Match user/token as jack/ccccccbcitfd [../pam_yubico.c:pam_sm_authenticate(1038)] done. [Success] I have just noticed that the 'flags' is set to 1 by ssh. I don't know where (or if) I can control how Dovecot sets that flag or if it has any relevance. The Pam configuration line for Yubikey is identical in the ssh configuration. Does anyone have any idea what is going wrong? Thanks in advance, Jack

1 0

identify MUA connecting?
by Juan Pablo 29 Jul '14

29 Jul '14

Hello I am using dovecot 1.2.15 on ubuntu. Is it possible to somehow log the MUA information that is connecting to Dovecot? The reason I am wanting to do this is I would like to know if people are getting their email on personal devices instead of work secured / standardized phones.

9 12

Missing IMAP Subfolders
by Tim 29 Jul '14

29 Jul '14

I've recently encountered an issue with my IMAP folders on Dovecot 2.0.19. When I telnet into my account and perform a list, I get the following response: A list "" "*" * LIST (\Unmarked) "." "INBOX" A OK List completed. However I know there are subfolders here and have examined the server directly via SSH and strangely: a select INBOX.Clients * OK [CLOSED] Previous mailbox closed. * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1394028715] UIDs valid * OK [UIDNEXT 1] Predicted next UID * OK [HIGHESTMODSEQ 1] Highest a OK [READ-WRITE] Select completed. When I also subscribe to a couple if these which I am able to to do despite not being able to "LIST" them, I get this with LIST-EXTENDED: a04 LIST (SUBSCRIBED RECURSIVEMATCH) "*" "*" * LIST (\Subscribed \NonExistent) "." "INBOX" (CHILDINFO ("SUBSCRIBED")) * LIST (\Subscribed \NonExistent) "." "INBOX.Clients" (CHILDINFO ("SUBSCRIBED")) * LIST (\Subscribed \NonExistent) "." "INBOX.Clients.Bob" a04 OK List completed. Just not sure why a LIST is not giving me a full list as it's causing problems subscribing to these with Mail Clients. Any help is appreciated!

1 0

incremental mailbox syncs for quick migration
by Jogi Hofmüller 29 Jul '14

29 Jul '14

Hi all, We are facing quite large mailboxes (>10GB) in our migration from cyrus to dovecot. I did a test on one mailbox and repeated the sync a couple of times with the expected result that the second, third, etc. sync took only seconds compared to minutes for the first sync. We use this command to sync a mailbox: doveadm backup -R -u USER imapc: Are there any problems to be expected when we first do a sync for all mailboxes but do not migrate the users right away but instead do the actual migration using a second sync? Cheers, -- j.hofmüller http://thesix.mur.at/

1 0