July 2010 - dovecot - dovecot.org

[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] Patch: 2.0 support for URLAUTH, BURL, CATENATE
by Mike Abbott 18 Apr '16

18 Apr '16

Thank you Timo for beginning the port of URLAUTH, BURL, and CATENATE from 1.2 to 2.0. Attached please find two patches that finish the port to 2.0. One patch updates the dovecot-2.0-urlauth branch and is based on the tip of that branch. The other patch adds the full support to dovecot-2.0.beta5. The resulting URLAUTH/BURL/CATENATE code is the same. Please let me know if you have any questions about these patches. Thanks.

4 9

[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 evaluation on a 30 gb mailbox
by Rajesh M 04 Nov '11

04 Nov '11

hi all i use qmail toaster. i recently changed over to dovecot. posting below my evaluation on the same my machine dual core dual xeon 5140 processor, with 4 gb ram, centos linux with qmailtoaster i had setup a qmail tap account which backups up data for a client of mine mailbox size over 30 gb setup dovecot with squirrelmail and logged in it had over one hundred and thirty nine thousand emails 139019 emails in the 30 gb mailbox Reports 1) first login : took 7 minutes to parse 139019 mails but never timed out. this was simply impossible with courier 2) the next login it took 5 seconds by which time the mail numbers increased to 139045 3) next i changed squirrelmail display preference to list 500 mails per page and then clicked on inbox ... expecting dovecot to take atleast around 1-2 mins to show the mails ... the mails were displayed in just 8 seconds .. awesome performance qmailtoaster is simply waiting for a dovecot integration i am evaluating the stability of dovecot now in the next 2-3 weeks i post stability report rajesh

19 43

[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] Automatic Debian Dovecot repository now also includes amd64 binary packages.
by Stephan Bosch 04 Jan '11

04 Jan '11

Hi, I've recently significantly improved the automated Dovecot Debian package builder. At the beginning it only produced i386 binaries for Debian testing. A few weeks back I added a slave builder that builds packages for Debian stable. Today I have extended the slave builder with support for multiple architectures and I've added amd64 binaries to the repository. The master builder still builds packages for testing/i386 every hour. The slaves check for new source packages about 20 minutes later. Read the following wiki page for more information and read it carefully when you are considering to use these packages: http://wiki.dovecot.org/PrebuiltBinaries#Automatically_Built_Packages Also, every day at four 'o clock in the morning, the latest source packages are uploaded to the openSUSE build service, which builds i386/amd64 binaries for several Ubuntu versions (experimental): http://download.opensuse.org/repositories/home:/sbosch:/ Regards, Stephan.

2 2

[Dovecot] Question about mbox_snarf and dovecot2.0
by Jonathan Siegle 18 Nov '10

18 Nov '10

Hello, I'm running revision 10622:de9d6dae7fe5 on AIX 5.3 with some local mods for our inbox hash function. I'm having a problem doing a "select inbox" when I use the mbox_snarf plugin. When I run truss on the process I see the following stat calls: 614528: kread(9, " 1 s e l e c t i n b".., 4096) = 15 614528: statx("/gpfs/inbox/14/tstem38", 0x0FFFFFFFFFFFF2F8, 176, 0) = 0 614528: statx("/gpfs/users/t/s/tstem38/IMAP//gpfs/inbox/14/.imap/tstem38", 0x0FFFFFFFFFFFED98, 176, 0) Err#2 ENOENT 614528: statx("/gpfs/users/t/s/tstem38/IMAP//gpfs/inbox/14/tstem38", 0x0FFFFFFFFFFFEDD8, 176, 0) Err#2 ENOENT 614528: statx("/gpfs/users/t/s/tstem38/IMAP", 0x0FFFFFFFFFFFEC88, 176, 0) = 0 614528: statx("/gpfs/users/t/s/tstem38/IMAP//gpfs/inbox/14/tstem38", 0x0FFFFFFFFFFFEDD8, 176, 0) Err#2 ENOENT 614528: statx("/gpfs/users/t/s/tstem38/IMAP", 0x0FFFFFFFFFFFEC88, 176, 0) = 0 and the client gets: 1 NO [CANNOT] Invalid mailbox name For pathing I have: plugin.conf: mbox_snarf = /gpfs/inbox/%Ju/%u and mail.conf:mail_location = mbox:%h:INBOX=/var/spool/mail/%Ju/%u I verified that not using the mbox_snarf works just fine. I have no namespaces enabled. Thanks, Jonathan

2 9

[Dovecot] (Single instance) attachment storage
by Timo Sirainen 17 Sep '10

17 Sep '10

Now that v2.0.0 is only waiting for people to report bugs (and me to figure out how to fix them), I've finally had time to start doing what I actually came here (Portugal Telecom/SAPO) to do. :) The idea is to have dbox and mdbox support saving attachments (or MIME parts in general) to separate files, which with some magic gives a possibility to do single instance attachment storage. Comments welcome. Reading attachments ------------------- dbox metadata would contain entries like (this is a wrapped single line entry): X1442 2742784 94/b2/01f34a9def84372a440d7a103a159ac6c9fd752b 2744378 27423 27/c8/a1dccc34d0aaa40e413b449a18810f600b4ae77b So the format is: "X" 1*(<offset> <byte count> <link path>) So when reading a dbox message body, it's read as: offset=0: <first 1442 bytes from dbox body> offset=1442: <next 2742784 bytes from external file> offset=2744226: <next 152 bytes from dbox body> offset=2744378: <next 27423 bytes from external file> offset=2744378 27423: <the rest from dbox body> This is all done internally by creating a single istream that lazily opens the external files only when data is actually tried to be read from that part of the message. The link paths don't have to be in any specific format. In future perhaps it can recognize different formats (even http:// urls and such). Saving attachments separately ----------------------------- Message MIME structure is being parsed while message is saved. After each MIME part's headers are parsed, it's determined if this part should be stored into attachment storage. By default it only checks that the MIME part isn't multipart/* (because then its child parts would contain attachments). Plugins can also override this. For example they could try to determine if the commonly used clients/webmail always downloads and shows the MIME part when opening the mail (text/*, inline images, etc). dbox_attachment_min_size specifies the minimum MIME part size that can be saved as an attachment. Anything smaller than that will be stored normally. While reading a potential attachment MIME part body, it's first buffered into memory until the min. size is reached. After that the attachment file is actually created and buffer flushed to it. Each attachment filename contains a global UID part, so that no two (even identical) attachments will ever contain the same filename. But there can be multiple attachment storages in different mount points, and each one could be configured to do deduplication internally. So identical attachments should somehow be stored to same storage. This is done by taking a hash of the body and using a part of it as the path to the file. For example: mail_location = dbox:~/dbox:ATTACHMENTS=/attachments/$/$ Each $ would be expanded to 8 bits of the hash in hex (00..ff). So the full path to an attachment could look like: /attachments/04/f1/5ddf4d05177b3b4c7a7600008c4a11c1 Sysadmin can then create /attachment/00..ff as symlinks to different storages. Hashing problems ---------------- Some problematic design decisions: 1) Hash is taken from hardcoded first n kB vs. first dbox_attachment_min_size bytes? + With first n kB, dbox_attachment_min_size can be changed without causing duplication of attachments, otherwise after the change the same attachment could get a hash to a different storage than before the change. - If n kB is larger than dbox_attachment_min_size, it uses more memory. - If n kB is determined to be too small to get uniform attachment distribution to different storages, it can't be changed without recompiling. 2) Hash is taken from first n bytes vs. everything? + First n bytes are already read to memory anyway and can be hashed efficiently. The attachment file can be created without wasting extra memory or disk I/O. If everything is hashed, the whole attachment has to be first stored to memory or to a temporary file and from there written to final storage. - With first n bytes it's possible for an attacker to generate lots of different large attachments that begin with the same bytes and then overflow a single storage. If everything is hashed with a secure hash function and a system-specific secret random value is added to the hash, this attack isn't possible. I'm thinking that even though taking a hash of everything is the least efficient option, it's the safest option. It's pretty much guaranteed to give a uniform distribution across all storages, even against intentional attacks. Also the worse performance isn't probably that noticeable, especially assuming a system where local disk isn't used for storing mails, and the temporary files would be created there. Single instance storage ----------------------- All of the above assumes that if you want a single instance storage, you'll need to enable it in your storage. Now, what if you can't do that? I've been planning on making all index/dbox code to use an abstracted out simple filesystem API rather than using POSIX directly. This work can be started by making the attachment reading/writing code use the FS API and then create a single instance storage FS plugin. The plugin would work like: open(ha/sh/hash-guid): The destination storage is in ha/sh/ directory, so a new temp file can be created under it. The hash is part of the filename to make unlink() easier to handle. Since the hash is already known at open() time, look up if hashes/<hash> file exists. If it does, open it. write(): Write to the temp file. If hashes/ file is open, do a byte-by-byte comparison of the inputs. If there's a mismatch, close the hashes/ file and mark it as unusable. finish(): a) If hashes/ file is still open and it's at EOF, link() it to our final destination filename and delete the temp file. If link() fails with ENOENT (it was just expunged), goto b. If link() fails with EMLINK (too many links), goto c. b) If hashes/ file didn't exist, link() the temp file to the hash and rename() it to the destination file. c) If the hashed file existed but wasn't the same, or if link() failed with EMLINK, link() our temp file to a second temp file and rename() it over the hashes/ file and goto a. unlink(): If hashes/<hash> has the same inode as our file and the link count is 2, unlink() the hash file. After that unlink() our file. One alternative to avoid using <hash> as part of the filename would be for unlink() to read the file and recalculate its hash, but that would waste disk I/O. Another possibility would to be to not unlink() the hashes/ files immediately, but rather let some nightly cronjob to stat() through all of the files and unlink() the ones that have link count=1. This could be wastefully inefficient though. Yet another possibility would be for the plugin to internally calculate the hash and write it somewhere. If it's at the beginning of the file, it could be read from there with some extra disk I/O. But is it worth it?.. Extra features -------------- The attachment files begin with an extensible header. This allows a couple of extra features to reduce disk space: 1) The attachment could be compressed (header contains compressed-flag) 2) If base64 attachment is in a standardized form that can be 100% reliably converted back to its original form, it could be stored decoded and then encoded back to original on the fly. It would be nice if it was also possible to compress (and decompress) attachments after they were already stored. This would be possible, but it would require finding all the links to the message and recreating them to point to the new message. (Simply overwriting the file in place would require there are no readers at the same time, and that's not easy to guarantee, except if Dovecot was entirely stopped. I also considered some symlinking schemes but they seemed too complex and they'd also waste inodes and performance.) Code status ----------- Initial version of the attachment reading/writing code is already done and works (lacks some error handling and probably performance optimizations). The SIS plugin code is also started and should be working soon. This code is very isolated and can't cause any destabilization unless it's enabled, so I'm thinking about just adding it to v2.0 as soon as it works, although the config file comments should indicate that it's still considered unstable.

5 31