[Dovecot] indexes permissions problem
Hey all, I did a search but didn't find the answer to my problem, so here goes. I've got a centos 6 server running Dovecot 2.0.beta6 (3156315704ef). For legacy reasons (I'm moving mail from a Dovecot 1.1.1 and FreeBSD box with user home directories NFS mounted), my index files are setup to be in /u/indexes/ On the Dovecot 1.1.1 installation, the perms on the indexes directory is 777 with root:mail ownership. The same thing on the Dovecot 2 / Centos server results in a 'permission denied' error when Dovecot tries to create files. So, I guess my main question is, what perms and ownership should /u/indexes be set to? I've tried several different things before this cry for help... Thanks. Mark
Re: [Dovecot] setacl fails - does not find dovecot-acl file
Hi, On Nov 4, 2011, at 10:39 PM, Timo Sirainen wrote: Nov 4 16:29:03 keira dovecot: imap(isa): Error: fcntl(unlock) locking failed for file /home/dovecot/isa/dovecot.index.log: No such file or directory Nov 4 16:29:03 keira dovecot: imap(isa): Error: fstat() failed with file /home/dovecot/isa/dovecot.index.log: No such file or directory These simply shouldn't happen. I'd say it's a kernel bug. You're running a default Ubuntu kernel? I wonder if other Ubuntu users have this problem. It may be an apparmor issue. I noticed plenty of apparmor log entries on these accesses, though apparmor should only log but not disallow them. I have unloaded the dovecot apparmor profiles and not seen any of these errors since then. I got a new issue, however: I migrated from Maildir to mdbox. Since then, my shared mailboxes don't fully work anymore. I have given another user full rights to a shared mailbox (getacl returns akxeilprwtscd for that folder/user). The user sees the mailbox an can perform some operations including reading and deleting messages on it. If she tries to insert a new message, however, it fails and the error log shows: dovecot: imap(isa): Error: fcntl(write-lock) locking failed for file /home/dovecot/michael/storage/dovecot.map.index.log: Bad file descriptor dovecot: imap(isa): Error: mail_index_wait_lock_fd() failed with file /home/dovecot/michael/storage/dovecot.map.index.log: Bad file descriptor All my mail locations are owned by the respective system user and the mail group, and writeable by both. In particular, I checked that both the storage directory as well as the dovecot.map.index.log are writeable by the mail group. The users are not regular members of the mail group, but my dovecot config contains mail_access_groups = mail Any idea how to resolve this issue? -Mike smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] Dovecot 2.0.15 quota configuration with mbox
On 09/11/11 18:56, Timo Sirainen wrote:
On Wed, 2011-11-09 at 10:54 +0100, David Ocana wrote:
I've been trying to set up dovecot 2.0.15, everything seems to work
pretty well except for the quota feature. I would like to set a quota
limit only for the Inbox folder. I configured two namespaces,
according to some posts from Timo Sirainen
namespace {
separator = /
prefix = INBOX/
location = mbox:/var/empty:INBOX=/mail/%d/%n:INDEX=/var/dovecot/%d/%n
inbox = yes
hidden = yes
}
plugin {
quota = dirsize:User quota
quota = dirsize:User quota:ns=INBOX/
Actually I forgot to mention that I also tried that, but I got the
following error:
Error: Initialization failed: Failed to initialize quota: Quota root
User quota: Unknown parameter for backend dirsize: ns=INBOX/
That's why I was trying to change quota settings by using the quota_rule
directive.
This limits the quota only to mailboxes in INBOX/ namespace.
# I've tried with:
quota_rule = INBOX:storage=819200K
quota_rule = INBOX/*:storage=819200K
quota_rule = INBOX/Inbox:storage=819200K
Quota rules don't work in this way. There are no per-mailbox quotas
really, at least in the way you're thinking about.
I see, I guess they're per-namespace quotas, right? I got the wrong idea
after watching the following, which was exactly what I wanted to do :p
quota_rule = mailbox name:limit configuration
May be that, using dirsize backend lets you no other option than
calculating quota for the whole user's mailbox?
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Dovecot] Please advise on very fast search
On 11/9/2011 11:35 PM, Alexander Chekalin wrote: Hello, Stan, in fact the only thing I miss even with my current scheme is permanent ID assigned to the message so I can easily find it despite the IMAP mailbox it is now (so if someone moved the message from one mailbox/folder to another, the ID allows to retrieve it fast anyway). You see, what I need is not only find message from|to someone on specified date, I also sometime need to restore that message back to user's original box. As far our mailserver and backup-mailserver are different machines, it is a bit tricky to copy messages between it fast enough. Say, if I need to find and restore all mails from u...@domain.com within 2009 year, and search yields in some 1000's of messages, then use IMAP to copy it over to another server takes some time - and if you consider both search time and restore/copy time the whole process may take ages. Apparently I didn't fully understand all of your requirements. Moving the archived mail to mbox/mdbox and/or getting a good indexing search engine installed will cut the search time down tremendously. Whether that would make up for the time consumed with an IMAP copy of many emails I don't know. If your servers aren't old and slow, and are not already overloaded, I would think the IMAP message copying over GbE would be pretty quick, even for the 1000 messages scenario. There may be some Dovecot tweaks that might make this copy process faster. Timo would need to chime in on that. Do you perform the IMAP transfers with a GUI IMAP client on your management PC? Or are you using imapsync or some other util directly on the servers? If the former you may be able to tweak your IMAP client to speed up the transfers as well. Try using IMAP and not IMAPS for the transfers. What is the network infrastructure between the servers and your management workstation? Is it all GbE with jumbo frames enabled? With maildir I can rsync/scp needed files to another host and that's fast way - that's why I stick with maildir. There is definitely some flexibility here. FTS in my case can help (I can search for u...@domain.com, for example), but it also return messages that contains such a string in message body (and that takes index space, too), so I'll need to filter it later, but surely it'll be faster than checking every message in the archive. Sure. So you're concerned with your poor performance, but also with disk space. Unfortunately there's no free lunch to be had. You'll have to make sacrifices somewhere. You could go with mdbox and use compression, trading that saved space for search index files space. -- Stan
Re: [Dovecot] Exim thru through Dovecot deliver to spec IMAP-folder
On 11/10/2011 3:27 AM, Alexander KIper wrote: Hello All! How can I post some mails from Exim trnasport through Dovecot deliver to IMAP MailBox in specific folder (for example: Junk)? Dovecot 1.x:http://wiki.dovecot.org/LDA/Sieve Dovecot 2.x:http://wiki2.dovecot.org/Pigeonhole/Sieve -- Stan
Re: [Dovecot] Please advise on very fast search
On 10.11.2011, at 6.37, Alexander Chekalin wrote: Are there any ways I can search or parse mboxes or mdboxes not directly and not with IMAP (I'm afraid it slooow in dump parsing)? See doveadm fetch / doveadm search. in fact the only thing I miss even with my current scheme is permanent ID assigned to the message so I can easily find it despite the IMAP mailbox it is now (so if someone moved the message from one mailbox/folder to another, the ID allows to retrieve it fast anyway). Dovecot has message GUIDs (with maildir it's filename), but there's no quick lookup for them, even though doveadm can fetch them easily: doveadm fetch text guid 12312312
Re: [Dovecot] Quota BUG - fixed
After some deep investigations I manage to solve the problem. I was only
reading quota in user_querry. Now I read it in user_querry and in
password_query and all seems fine:
--dovecot-sql.conf---
user_query = SELECT '/home/%d/%n' as home, 'maildir:/home/%d/%n' as mail, 150
AS uid, 8 AS gid, CONCAT('*:bytes=', quota) AS quota_rule FROM mailbox WHERE
username = '%u' AND active = '1'
password_query = SELECT username as user, password, '/home/%d/%n' as
userdb_home, 'maildir:/home/%d/%n' as userdb_mail, 150 as userdb_uid, 8 as
userdb_gid, CONCAT('*:bytes=', quota) as userdb_quota_rule FROM mailbox WHERE
username = '%u' AND active = '1'
--dovecot.conf---
plugin {
quota = dict:user::proxy::quotadict
quota_rule2 = Trash:storage=10%%
quota_rule3 = SPAM:storage=10%%
}
the result is fine now:
2 getquotaroot inbox
* QUOTAROOT INBOX user
* QUOTA user (STORAGE 1997999 200)
2 OK Getquotaroot completed.
Only one cosmetic bug remains when an empty mailbox appear as a small
negative number in quota2 table, but this is fixable in postfixadmin.
--
Best regards,
Adrian MintaMA3173-RIPE,www.minta.ro
[Dovecot] dovecot-lda quota rule
I really like the feature where you can define quota rules with percents which trigger off of the default values[0] (so you can set the Trash to allow for 10% more of the user's quota for example). What I would really love in dovecot would be for the ability to configure a quota rule for dovecot-lda. I would like to configure things so we don't bounce emails for users until they are well over quota, the IMAP quota plugin is a really great way to notify people that they are over quota because it fails to write to other folders that should be enough to get people's attention that they need to deal with things, but bouncing is harsh. Is there a way to do this now that I haven't seen? thanks! micah 0. http://wiki2.dovecot.org/Quota/Configuration -- pgpaJaa1mOJFt.pgp Description: PGP signature
[Dovecot] TLS Authentication Confusion
I asked a user today to make sure his incoming and outgoing email was using TLS. He told me it wasn't possible because my Dovecot / Postfix daemons were only listening on TCP 25 143 according to a port scan he did. He told me the only way I could enable encrypted secure sessions between the client server is to enable port 993 (IMAPs). I told him that TLS is supported on my mail server over the default ports TCP 25 / 143 and that many consider IMAPs to be legacy. I sent him a telnet session of my PC communicating with my server it shows TLS is available. I just wanted to be sure I was correct with the information above or am I completely wrong and I do indeed need TCP port 993? I know this is the Dovecot mailing list but since Dovecot and Postfix both use and support TLS in their configuration files, I figured I would ask here for your help! carloss@pc1:~$ telnet mail.holyghost.org 25 Trying 192.168.4.100... Connected to mail.holyghost.org. Escape character is '^]'. 220 mail.holyghost.org ESMTP Postfix EHLO pc1.holyghost.org 250-mail.holyghost.org 250-PIPELINING 250-SIZE 2048 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN Below is a snip from my mail logs showing TLS: Nov 9 10:26:39 mail dovecot: imap-login: Login: user=carlos, method=PLAIN, rip=:::192.168.4.100, lip=:::192.168.4.100, TLS The above snip from my log means that I'm connecting to Dovecot via TLS, correct?
Re: [Dovecot] TLS Authentication Confusion
On 11/10/11 19:17, Carlos Mennens wrote: I asked a user today to make sure his incoming and outgoing email was using TLS. He told me it wasn't possible because my Dovecot / Postfix daemons were only listening on TCP 25 143 according to a port scan he did. He told me the only way I could enable encrypted secure sessions between the client server is to enable port 993 (IMAPs). Yes you are right. Port 993 is for IMAPS (SSH). TLS is normally on the same port as plain. The difference between SSH and TLS is that with SSH the encryption is set up before any application communication takes place. i.e all application packets are contained in the encrypted payload. With TLS the application starts communication and then the application sets up encryption of its payload. Dick
Re: [Dovecot] patching dovecot for sieve/managesieve support, centos 5.6?
This mail was answered before. Don't repost your question unless you have acted on the information provided, got new information or have additional questions. Re-posting the exact same message makes no sense. Regards, Stephan. On 11/10/2011 5:09 AM, Scott Lewis wrote: - Forwarded Message - From: Scott Lewisscott_the_music...@yahoo.com.au To: dovecot@dovecot.orgdovecot@dovecot.org Sent: Thursday, 3 November 2011 4:31 PM Subject: patching dovecot for sieve/managesieve support, centos 5.6? Hi all, I am having real trouble when attempting to patch dovecot 1.2 to include the Pidgeonhole sieve support on my CentOS 5.6 x64 mail server. I am relatively new to the programming side of linux, but I am not having a lot of luck when trying to get this thing to compile. Here's what happens: [root@mail ~]# whereis dovecot dovecot: /usr/sbin/dovecot /etc/dovecot.conf /usr/lib/dovecot /usr/libexec/dovecot /usr/share/man/man8/dovecot.8.gz [root@mail dovecot-1.2-sieve-0.1.19]# ./configure --with-dovecot=/usr/lib/dovecot ... checking whether to build static libraries... yes dovecot-config not found from /usr/lib/dovecot, use --with-dovecot=PATH to give path to compiled Dovecot sources or to a directory with the installed dovecot-config file. configure: error: dovecot-config not found -- I get this message regardless of whether I set --with-dovecot as /usr/sbin/dovecot, or /etc, or /usr/libexec/dovecot. I have SquirrelMail 1.4.22 running, and the avelsieve front-end seems happy enough. when I visit https://mail.mydomain.com/src/configtest.php, I get: Avelsieve plugin details: backend = ManageSieve ERROR: I could not determine the capabilities for Sieve Mail Filtering. Perhaps connectivity with ManageSieve server (if backend=Managesieve) is bad? thanks in advance!
Re: [Dovecot] TLS Authentication Confusion
On Thu, 10 Nov 2011 19:28:55 + Dick Middleton wrote: On 11/10/11 19:17, Carlos Mennens wrote: I asked a user today to make sure his incoming and outgoing email was using TLS. He told me it wasn't possible because my Dovecot / Postfix daemons were only listening on TCP 25 143 according to a port scan he did. He told me the only way I could enable encrypted secure sessions between the client server is to enable port 993 (IMAPs). Yes you are right. Port 993 is for IMAPS (SSH). TLS is normally on the same port as plain. The difference between SSH and TLS is that with SSH the encryption is set up before any application communication takes place. i.e all application packets are contained in the encrypted payload. With TLS the application starts communication and then the application sets up encryption of its payload. :%s/SSH/SSL/g --Frank
Re: [Dovecot] TLS Authentication Confusion
On 10-11-11 20:28, Dick Middleton wrote: On 11/10/11 19:17, Carlos Mennens wrote: I asked a user today to make sure his incoming and outgoing email was using TLS. He told me it wasn't possible because my Dovecot / Postfix daemons were only listening on TCP 25 143 according to a port scan he did. He told me the only way I could enable encrypted secure sessions between the client server is to enable port 993 (IMAPs). Yes you are right. Port 993 is for IMAPS (SSH). TLS is normally on the same port as plain. The difference between SSH and TLS is that with SSH the encryption is set up before any application communication takes place. i.e all application packets are contained in the encrypted payload. With TLS the application starts communication and then the application sets up encryption of its payload. You're contributing to the confusion. SSL and TLS are practically the same, just another name for the same beast. The only difference is that SSL is the old name, and newer versions of the standard are labeled TLS. The term SSH is not in the scope of this question. There are 2 ways of using SSL/TLS to encrypt sessions: 1) Setup a dedicated port where a SSL/TLS session can be setup before the actual data is transferred. This is what happens for IMAPS/993 and SMTPS/465. 2) Extend an existing protocol to enable SSL/TLS during an open session. This is called STARTTLS in several protocols, SMTP and IMAP being among them. And this is what happens on SMTP/25, Submission/587 and IMAP/143. Note that although the second option is *named* STARTTLS, you probably could implement any server to *use* SSL 1.0 for the actual encryption (not recommended though). The OP is offering STARTTLS for both services, which is good. -- Regards, Tom
Re: [Dovecot] TLS Authentication Confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2011 2:11 PM, Tom Hendrikx wrote: On 10-11-11 20:28, Dick Middleton wrote: On 11/10/11 19:17, Carlos Mennens wrote: I asked a user today to make sure his incoming and outgoing email was using TLS. He told me it wasn't possible because my Dovecot / Postfix daemons were only listening on TCP 25 143 according to a port scan he did. He told me the only way I could enable encrypted secure sessions between the client server is to enable port 993 (IMAPs). Yes you are right. Port 993 is for IMAPS (SSH). TLS is normally on the same port as plain. The difference between SSH and TLS is that with SSH the encryption is set up before any application communication takes place. i.e all application packets are contained in the encrypted payload. With TLS the application starts communication and then the application sets up encryption of its payload. You're contributing to the confusion. SSL and TLS are practically the same, just another name for the same beast. The only difference is that SSL is the old name, and newer versions of the standard are labeled TLS. The term SSH is not in the scope of this question. There are 2 ways of using SSL/TLS to encrypt sessions: 1) Setup a dedicated port where a SSL/TLS session can be setup before the actual data is transferred. This is what happens for IMAPS/993 and SMTPS/465. 2) Extend an existing protocol to enable SSL/TLS during an open session. This is called STARTTLS in several protocols, SMTP and IMAP being among them. And this is what happens on SMTP/25, Submission/587 and IMAP/143. Note that although the second option is *named* STARTTLS, you probably could implement any server to *use* SSL 1.0 for the actual encryption (not recommended though). The OP is offering STARTTLS for both services, which is good. -- Regards, Tom The confusion is caused by the way some client software differentiate these services in their configuration, often referring to wrappermode smtps/imaps as SSL, and STARTTLS as TLS. -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOvDJcAAoJEHIluGOd3V4F6foH/16+xq91/j4hgXufdnAsxwW1 N2ZXf1fby7TjR4BpaYNdH6PsN5/UqFSZItVYkeDXWgGG/wYCTRC+LHdks/EeQKgR 1ondUL2iorQ7bGy25m3526DGShFmcEh7P+Z6WWwdFeOTLBS57LIgwvFHBg4niYHq 3ZbPOjzI+d7kbz8tT8ATb+Ju+uJlV2rpbZKHQ90qlOR9tRl6bUOEeW32yPf5hjpI gs89o66Ud+mb9kkH9vgrhnutxsWjVxWNWM1ba43S1bh4Jg9YneIdsHdQVQSPrFUz EPy5Tgz3b+LZC6lwe6czFrhYgv/GUiJutS34qRHLSMAQGY+fgOcZBSZQHKP7NC4= =TdNE -END PGP SIGNATURE-
Re: [Dovecot] LDAP expired password
rpalmarin rpalma...@yahoo.com wrote: Sven Hartge sven at svenhartge.de writes: Nikolaos Milas nmilas at noa.gr wrote: On 1/4/2011 11:09 πμ, Sven Hartge wrote: Have a look at the ppolicy slapd.overlay. This will solve your problem. Sorry for the delay in the response I checked the ppolicy overlay but without success. This overlay does not have a single password expired attribute to put in the user_filter. I think you misunderstood the usage of the overlay. There is _no_ additional attribute to check. With ppolicy any authentication will fail if some previously defined conditions are met (or no longer met) like the max age of a password. Documentation is contained in man slapo-ppolicy, which as bit hard to understand, I must admit. Also look at http://www.openldap.org/doc/admin24/overlays.html 12.10 Password Policies has a nice example. With this overlay you don't need any additional attributes and no maintenance or houskeeping script to invalidate expired passwords. At my university we introduced our own attribute gifb-status which contains a 1 if an account is valid, a 0 if it is not (and several others for different purposes) and our ldap-filters all contain something like ((ou=foobar)(gifb-status=1)). is possible that the only way to do this is to manage a new attribute? how can understand all the people that have configured the mail client to authenticate with imap-dovecot that their passoword has expired? Well, either way (using ppolicy or an additional attribute): they will call the support desk, if they are unable to understand the message from their mail client. No way to fix _this_ problem, I am afraid ;) S° -- Sigmentation fault. Core dumped.
