January 2010 - 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] dovecot user
by Timo Sirainen 04 May '10

04 May '10

Any thoughts on this: The primary use for "dovecot" user has been for login processes. But people keep misunderstanding this and try to use dovecot for accessing mails. For years I've been wondering about renaming this user to something else like dovelogin, but it never really seemed practical. So now with v2.0 there are a bunch of new processes, and for example anvil and dict are now run as dovecot user by default. But it's not really good that login processes can just go and kill those processes. And even worse, if drop_priv_before_exec=yes they could ptrace these processes. So I think we need two Dovecot users for v2.0: 1. Completely untrusted user for login processes. 2. Slightly more trusted internal Dovecot user. So "dovecot" could be reused for 2. And it would no longer be a mortal sin to use dovecot user for owning mail files. For 1. there would be a new user. I'd use "dovelogin", but apparently tools still don't much like usernames that are longer than 8 characters. Like ps could show numeric uid instead of 9 character long username. So .. any suggestions? "dovlogin" could be one possibility I guess. It would be nice if the name somehow reminded of login processes, but maybe something else could be used too, like: dovenil, dovenull, dovezero, dovenone, dovevoid, doveint, dovedown, dovein, dove0

17 33

[Dovecot] simple steps with sieve
by Gavin Hamill 03 Apr '10

03 Apr '10

Today is my first day with sieve, so be gentle :) I'm trying to set up a pretty webmail interface to our Dovecot 1.2.4 server using roundcube. The managesieve config + roundcube 'managesieve' plugin work fine, and I'm able to use roundcube's UI to generate .dovecot.sieve files. We use winbind + LDAP lookups to do some exotic mail rewriting... ultimately user.name(a)domain.com gets rewritten to 'ar-cloh@localhost', and in /home/AD/ar-cloh/.dovecot.sieve there is only this: require ["vacation"]; # rule:[gdh_test] if anyof (header :contains "Subject" "test") { vacation "test away"; } When I send an email to the user, I see this in the mail.log Oct 19 15:39:43 ar-smtp-1 dovecot: deliver(ar-cloh): sieve: msgid=<1255963176.14420.31.camel@gdh-work>: discarding vacation response for message implicitly delivered to <ar-cloh@ar-smtp-1> I don't understand; sending a vacation for implicitly-delivered messages sounds exactly like what I want - is there any way to say 'do this anyway' ? gdh

8 18

[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] antispam plugin
by Dan Swartzendruber 24 Feb '10

24 Feb '10

First off, I have to say I really like the antispam plugin. I am running a (relatively) new freebsd 8.0 server with postfix/dovecot/dspam/squirrelmail and it works great. Create a SPAM folder and tell the dovecot antispam plugin to use INBOX.SPAM as the spam folder and drag messages from INBOX to the spam folder and they are trained as spam. Here is the problem though: after training dspam for a couple of weeks, I had a couple hundred messages in the SPAM folder, so I selected them and hit the DELETE button and they were gone. Except they weren't. I had forgotten that by default squirrelmail moves deleted messages to a Trash folder under INBOX. So the messages were moved out of the SPAM folder, resulting in them being retrained as ham. Oops :( I then hit the purge link in squirrelmail and the messages were forever gone, so I couldn't rectify my gaffe. I have temporarily reconfigured squirrelmail to delete messages outright rather than save them in the Trash folder, but I don't like that as a long-term solution. What occurred to me is this: the current algorithm is: if message moves from * => SPAM, it is trained as spam, if it moves from SPAM => *, it is trained as ham. It would be nice if you could elaborate on that such that the ham rule was "if message moves from SPAM to X, it is ham" (and in my case, I would defined X as INBOX. Thoughts?

3 7

[Dovecot] dovecot-sieve and ldap user
by spamvoll＠googlemail.com 18 Feb '10

18 Feb '10

hi.. im running dovecor 1.2.10 and dovecot-sieve 0.1.15 protocol lda { .. mail_plugins = sieve } plugin { ... sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } cat .dovecot.sieve require "fileinto"; if header :contains "subject" ["VIRUS"] { fileinto "VIRUS"; } else { keep; } But mails dont get moved. I use the master.cf to get postfix to use deliver dovecot unix - n n - 10 pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -d ${recipient} dovecot -n # 1.2.10: /etc/dovecot.conf # OS: Linux 2.6.18-164.10.1.el5 i686 CentOS release 5.4 (Final) protocols: imaps ssl: required login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login first_valid_uid: 10000 last_valid_uid: 10000 first_valid_gid: 10000 last_valid_gid: 10000 mail_uid: vmail mail_gid: vmail lda: postmaster_address: postmaster(a)example.com mail_plugins: sieve auth_socket_path: /var/run/dovecot/auth-master auth default: passdb: driver: ldap args: /etc/dovecot-ldap.conf userdb: driver: passwd userdb: driver: ldap args: /etc/dovecot-ldap.conf socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: sieve: ~/.dovecot.sieve sieve_dir: ~/sieve Does the sieve plugin use the home_dir returned from the ldap ? And is it ok to use the deliver in master.cf and or do i have to set mailbox_command = /usr/lib/dovecot/deliver ?

2 1