August 2009 - dovecot

[Dovecot] [PATCH, RFC] add APOP authentication mechanism
by Andrey Panin 14 Aug '17

14 Aug '17

Hello all, this patch add APOP authentication mechanism to dovecot 1.0-test23. Please take a look. Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke(a)donpac.ru | PGP key: wwwkeys.pgp.net

3 2

[Dovecot] Sieve vacation not working
by Phill Edwards 24 Feb '15

24 Feb '15

I've been trying all night to get vacation working in my .dovecot.sieve file. The way our email works is we have one account on dovecot which serves my mail and my wife's and we use procmail and sieve to put the emails in different folders depending on who it's for. I'm trying to set up a vacation reply on my wife's email address (aaaaaaaa@optus* below) so people can update to her new address. Here's my file with the email addresses masked: require ["fileinto", "vacation"]; if address :is "to" "xxxxxxxxxxxxxxx(a)ozemail.com.au" { fileinto "Phill_OzEmail_Folder"; stop; } elsif address :is "to" "yyyyyyyyyyyyyyyyy(a)optusnet.com.au" { fileinto "Phill_Optus_Folder"; stop; } elsif address :matches "to" "aaaaaaaa@optus*" { vacation "Please update my email address to bbbbbbbbb(a)exemail.com.au"; fileinto "Sarah_Optus_Folder"; stop; } else { keep; stop; } The problem I'm having is that no auto-replies are sent. I removed .dovecot.lda-dupes and that didn't help; so then I touched it and now it's a 0 byte file and that didn't help. There is no dovecot.sieve.err file and I can't see anything in /var/log/dovecot.log which gives any message about why this wouldn't work. The emails to aaaaaaa@optus* get filed into the right folder so I know the matching is working. I've also tried a reject recipe and that worked fine, so I know that it can send an email if it chooses to. So it's a complete black box mystery as to why it just won't send a reply. Regards, Phill

5 9

[Dovecot] Auth worker max line size
by Emmanuel Dreyfus 09 Sep '12

09 Sep '12

Hello I have been playing with some exotic authentication scheme with Dovecot and PAM. That involves sending really large base64 encoded data as the IMAP password, and I have hit a line limit in Dovecot, with AUTH_WORKER_MAX_LINE_LENGTH set to 1024. This limit is especially frustrating since other parts of the software use much larger limits: MAX_INBUF_SIZE 4096 MAX_IMAP_LINE 8192 AUTH_CLIENT_MAX_LINE_LENGTH 8192 I had to make the patch attached below to get my authentication working. I can live with this local patch, but given the much more liberal limits of MAX_INBUF_SIZE at 4096 makes we wonder if this 1024 limit on AUTH_WORKER_MAX_LINE_LENGTH could not be a bug. Or is there a security concern at using more than 1kB? Opinions? (please Cc: me, I'm not subscribed ot the list) --- src/auth/auth-worker-client.h.orig 2009-06-23 18:32:15.000000000 +0200 +++ src/auth/auth-worker-client.h 2009-06-23 18:32:33.000000000 +0200 @@ -1,8 +1,8 @@ #ifndef AUTH_WORKER_CLIENT_H #define AUTH_WORKER_CLIENT_H -#define AUTH_WORKER_MAX_LINE_LENGTH 1024 +#define AUTH_WORKER_MAX_LINE_LENGTH 4096 struct auth_worker_client *auth_worker_client_create(struct auth *auth, int fd); void auth_worker_client_destroy(struct auth_worker_client **client); void auth_worker_client_unref(struct auth_worker_client **client); -- Emmanuel Dreyfus manu(a)netbsd.org

3 5

[Dovecot] dovecot 1.2.3: TB fails to unsubscribe folder after deletion
by Max Dittrich 07 Mar '11

07 Mar '11

Hi, I'm running dovecot 1.2.3 with "imap_client_workarounds = tb-extra-mailbox-sep" and noticed that after deleting a folder (moving to Trash and emptying it on exit) that folder in Trash still keeps subscribed. I think the reason for that behavior is that the call for mailbox_list_set_subscribed() in imap/cmd-subscribe.c (line 84) is fed with the original mailbox name and not the stripped version in verify_name. Assigning verify_name to mailbox in the workaround-conditional fixes this issue for me. I'm not very familiar with C programming but while tracing cmd_subscribe_full() I stumbled upon another thing. In mail_namespace_find_mask() (lib-storage/mail-namespace.c at line 413) mailbox is reassigned with a local string (not t_strduped). I think this might be a problem when mailbox is dereferenced after returning from that function?! .max

3 10

[Dovecot] Can't connect to auth server
by Phill Edwards 13 Feb '11

13 Feb '11

I'm trying to phase out procmail and move to dovecot-sieve instead. It ain't proving easy. I'll describe my setup: - Centos 5.2 box with dovecot 1.1.4 and dovecot-sieve 1.1.6 from ATrpms. - A single user account is used to store all our email (the account is called maildb). - Getmail is being used to fetch the email from various ISP mailboxes. I want to deliver mail to different folders in maildb's Maildir/ depending on who the email is addressed to (the procmail recipes currently do that). - Getmail destination section looks like this: [destination] type = MDA_external path = /usr/libexec/dovecot/deliver arguments = ("-d", "maildb") allow_root_commands = true - When I run getmail I get this error in dovecot.log: deliver(maildb): May 04 22:15:26 Error: Can't connect to auth server at /var/run/dovecot/auth-master: No such file or directory It's true that I don't have a file called auth-master. I guess I should have but until I started this dovecot-sieve work it was never a problem. I have no idea what that file should look like. As I installed from binary RPMs I would have thought one would have come with the install. Can anyone help? Regards, Phill

4 6

[Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
by Timo Sirainen 12 Mar '10

12 Mar '10

This is something I figured out a few months ago, mainly because this one guy at work (hi, Stu) kept telling me my multi-master replication plan sucked and we should use some existing scalable database. (I guess it didn't go exactly like that, but that's the result anyway.) So, my current plan is based on a couple of observations: * Index files are really more like memory dumps. They're already in an optimal format for keeping them in memory, so they can be just mmap()ed and used. Doing some kind of translation to another format would just make it more complex and slower. * I can change all indexing and dbox code to not require any locks or overwriting files. I just need very few filesystem operations, primarily the ability to atomically append to a file. * Index and mail data is very different. Index data is accessed constantly and it must be very low latency or performance will be horrible. It practically should be in memory in local machine and there shouldn't normally be any network lookups when accessing it. * Mail data on the other hand is just written once and usually read maybe once or a couple of times. Caching mail data in memory probably doesn't help all that much. Latency isn't such a horrible issue as long as multiple mails can be fetched at once / in parallel, so there's only a single latency wait. So the high level plan is: 1. Change the index/cache/log file formats in a way that allows lockless writes. 2. Abstract out filesystem accessing in index and dbox code and implement a regular POSIX filesystem support. 3. Make lib-storage able to access mails in parallel and send multiple "get mail" requests in advance. (3.5. Implement async I/O filesystem backend.) 4. Implement a multi-master filesystem backend for index files. The idea would be that all servers accessing the same mailbox must be talking to each others via network and every time something is changed, push the change to other servers. This is actually very similar to my previous multi-master plan. One of the servers accessing the mailbox would still act as a master and handle conflict resolution and writing indexes to disk more or less often. 5. Implement filesystem backend for dbox and permanent index storage using some scalable distributed database, such as maybe Cassandra. This is the part I've thought the least about, but it's also the part I hope to (mostly) outsource to someone else. I'm not going to write a distributed database from scratch.. This actually should solve several issues: * Scalability, of course. It'll be as scalable as the distributed database being used to store mails. * NFS reliability! Even if you don't care about any of these alternative databases, this still solves NFS caching problems. You'd keep using the regular POSIX FS API (or async FS api) but with the in-memory index "cache", so only a single server is writing to mailbox indexes at the same time. * Shared mailboxes. The filesystem API is abstracted, so it should be possible to easily add another layer to handle accessing other users' mails from both local and remote servers. This should finally make it possible to easily support shared mailboxes with system users.

17 82

[Dovecot] Capability COMPRESS implemented?
by Ed W 15 Feb '10

15 Feb '10

Hi, I just read that http://tools.ietf.org/html/rfc4978 ..is being implemented in Thunderbird 3. This is great news! It's been a long time since we last discussed this and I don't think it's currently implemented in Dovecot, but since Cyrus just added it, any chance of getting support in Dovecot please? (Fastmail seems to be supporting this effort) On a similar note we had a previous thread about supporting TLS deflate - any chance you could investigate this again and add support on the Dovecot side so at least it would be feasible to submit a bug fix on the Thunderbird side? (It looked like a one liner change back when we last discussed it?) Thanks Ed W (Obviously for those looking for an external high performance compressor you can use our compressing email proxy from http://www.mailasail.com ...)

3 14

[Dovecot] Two different issues with dovecot 1.1.13
by Stuart Rowan 20 Jan '10

20 Jan '10

Hi Timo, I'm using Debian backports.org dovecot-imapd, 1:1.1.13-2~bpo50+1. I've got two different issues, a reoccurring, seemingly harmless one about "Corrupted index cache file" (boring.txt) and one that went bonkers over the least few days (bt.txt) causing much spamming of the logs. I've made bt.txt stop happening by just rm'ing dovecot.index* : find Maildir/ -type f -name 'dovecot.index*' -print0 | xargs -0r rm ... which I realise may not be the most helpful thing to have done from your point of view. Anyway I just wanted to let you know about both of these. If one or both are already known about or already fixed by a later version of Dovecot, great and sorry for the noise! If not, and you want any more information etc., let me know. Many thanks, Stu. dovecot: 2009-07-28 10:23:16 Error: IMAP(strr): Corrupted index cache file /home/local/strr/Maildir/dovecot.index.cache: record continues outside its allocated size dovecot: 2009-07-28 10:23:56 Error: IMAP(strr): Corrupted index cache file /home/local/strr/Maildir/dovecot.index.cache: record continues outside its allocated size dovecot: 2009-07-28 08:05:54 Panic: IMAP(strr): file index-mail-headers.c: line 77 (index_mail_parse_header_finish): assertion failed: ((match[match_idx] & HEADER_MAT CH_FLAG_FOUND) == 0) dovecot: 2009-07-28 08:05:54 Error: IMAP(strr): Raw backtrace: imap [0x48dbf2] -> imap [0x48dc73] -> imap [0x48d346] -> imap(index_mail_parse_header+0x617) [0x4545f7] -> imap [0x483284] -> imap [0x483478] -> imap(i_stream_read+0x2c) [0x491d7c] -> imap(i_stream_read_data+0x46) [0x491f16] -> imap(message_get_body_size+0x108) [0x4885 a8] -> imap [0x4226c3] -> imap(imap_fetch+0x162) [0x420852] -> imap(cmd_fetch+0x23c) [0x41a27c] -> imap [0x41e46c] -> imap [0x41e51d] -> imap [0x41eb25] -> imap(clien t_input+0x63) [0x41efd3] -> imap(io_loop_handler_run+0xcb) [0x49515b] -> imap(io_loop_run+0x18) [0x4945c8] -> imap(main+0x3da) [0x426bea] -> /lib/libc.so.6(__libc_sta rt_main+0xe6) [0x7f0e851941a6] -> imap [0x418859] dovecot: 2009-07-28 08:05:54 Error: child 20007 (imap) killed with signal 6 (core dumps disabled) dovecot: 2009-07-28 08:05:56 Panic: IMAP(strr): file index-mail-headers.c: line 77 (index_mail_parse_header_finish): assertion failed: ((match[match_idx] & HEADER_MAT CH_FLAG_FOUND) == 0) dovecot: 2009-07-28 08:05:56 Error: IMAP(strr): Raw backtrace: imap [0x48dbf2] -> imap [0x48dc73] -> imap [0x48d346] -> imap(index_mail_parse_header+0x617) [0x4545f7] -> imap [0x483284] -> imap [0x483478] -> imap(i_stream_read+0x2c) [0x491d7c] -> imap(i_stream_read_data+0x46) [0x491f16] -> imap(message_get_body_size+0x108) [0x4885 a8] -> imap [0x4226c3] -> imap(imap_fetch+0x162) [0x420852] -> imap(cmd_fetch+0x23c) [0x41a27c] -> imap [0x41e46c] -> imap [0x41e51d] -> imap [0x41eb25] -> imap(clien t_input+0x63) [0x41efd3] -> imap(io_loop_handler_run+0xcb) [0x49515b] -> imap(io_loop_run+0x18) [0x4945c8] -> imap(main+0x3da) [0x426bea] -> /lib/libc.so.6(__libc_sta rt_main+0xe6) [0x7f2edf08b1a6] -> imap [0x418859] dovecot: 2009-07-28 08:05:56 Error: child 20984 (imap) killed with signal 6 (core dumps disabled)

2 5

[Dovecot] Berlin talk - video or audio available?
by James Brown 25 Nov '09

25 Nov '09

Thanks Timo for putting up the .pdf and .ppt files for your talk at www.dovecot.org/talks . Is there a video or audio file of it? Thanks, James.

3 2

[Dovecot] Sieve vacation with russian subject
by Nikita Koshikov 28 Oct '09

28 Oct '09

Hello list, I have noticed that sieve vacation action breaks some non-english letters in the subject. I tested with russian language, if subject contains letters from specific diapason russian alphabet, the message received with unreadable subject, but text in the body with the same letters looks ok. Here is example of full subject header, it contains russian alphabet: Subject: абвгде�?жзийклмноп�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�? Maybe this headers will be usefull: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit .dovecot.sieve file looks correct, here is it: require ["vacation"]; # rule:[test] if anyof (true) { vacation :days 1 :addresses ["user(a)domain.com"] :subject "абвгдеёжзийклмнопрстуфхцчшщъыьэюя" text: Тестовое русское сообщение(Test russian message). ; } I'm running dovecot-1.1.16 with dovecot-sieve-1.1.6 and managesieve-0.10.6. Please tell, is it possible to fix this ?

7 10