[Dovecot] delegation of admin rights
Hello, We're a rather largish university (largest in Israel), with some 60-70k users, using Dovecot 1.2.14 (we're cautious about moving to 2.0.x for now). We need to provide admin rights to faculty computer/IT staff, so they can have access to the mailboxes of their respective users. We use LDAP as an authentication/authorization backend. Currently, dovecot has a "master user" which can access all mailboxes. I am looking for a solution, preferably within dovecot, to create a delegation type of administration, allowing certain users to access the mailboxes of other users based on an LDAP filter or LDAP attribute value. If possible, allowing per protocol access(that is, I would like to give them IMAP access and not POP3) and within IMAP allowing only to view a mailbox, but not to change it, that would be even better. Does anyone on this list know of any IMAP proxy providing such abilities, and also, would the Dovecot team consider this as a candidate for a request for enhancement ? This would be very useful in a delegated administration environment, like most larger organizations, hosting & ISP, and other environments where delegation is an important and very much needed ability. thanks a bunch, -- Ariel -- Ariel Biener e-mail: ar...@post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html
Re: [Dovecot] nfs director
We're a similar installation (60-70k users, FAS3050 cluster). We have been using "perdition" (IMAP/POP redirector) software for a while. The IMAP/POP.ourdomain A records point to 2 front ends, which all they do is to redirect the IMAP/POP session to the a specific mail server for each user, based on their LDAP mailhost entry. We use postfix to deliver mail, and procmail is the LDA. We are running a background process on each mail server (3 mailservers which do SMTP/POP/IMAP, and barely sweat at it - 2xquad core Xeons with 8gig each), which monitors the maillog, and if dovecot sees a index corruption, the monitor fixes the problem (we used to see these errors when we still used mbox, not anymore though). We run a periodic process, which gets statistics of usage from the mail servers, and reassign the users to mail servers in order to better distribute the load. Each new user that is created gets his mail server by a random function which choses one of the three. Each mail server in the user LDAP entry is in fact a virtual address on a load balancer, pointing to the real mail server behind it, BUT also having a backup server for each in case the real server crashes, so assuming mailsrv1 crashes, mailsrv2 will take its clients. The setup works rather well, within the limitations of maildir and netapp (mainly full body search being slowish with very large mailboxes made out of 10s of thousands of files). We used to not use the "perdition" directors in the past, and once we started using them, we saved alot of problems on a few fronts: 1. Index corruption issues 2. SSL termination - since the front ends to the SSL termination, the backend servers access from the front ends is clear text, saving CPU cycles from the backends servers. I haven't taken a look yet at Dovecot's solution for the director, but I am writing this since I do think that it is addressing a real life problem for any medium++ or larger installation that uses NFS. Oh, and Timo, I don't think we are just "a couple of NFS users". Maildir and NFS are not as uncommon as you'd think, even in very large installations. --Ariel Brandon Davidson wrote: > Noel, > > On 8/26/10 9:59 PM, "Noel Butler" wrote: > > >>> I fail to see advantage if anything it add in more point of failure, with >>> >> i agree with this and it is why we dont use it >> >> we use dovecots deliver with postfix and have noticed no problems, not >> to say there was none, but if so, we dont notice it. >> > > We might be a slightly larger install than you (60k users, mail on FAS 3170 > Metrocluster), but we have noticed corruption issues and the director is > definitely going to see use in our shop. We still use Sendmail+procmail for > delivery, so no issue there... but we've got hordes of IMAP users that will > leave a client running at home, at their desk, on their phone, and then will > use Webmail on their laptop. > > Without the director, all of these sessions end up on different backend > mailservers, and it's basically a crapshoot which Dovecot instance notices a > new message first. NFS locking being what it is, odds are an index will get > corrupted sooner or later, and when this happens the user's mail > 'disappears' until Dovecot can reindex it. The users inevitably freak out > and call the helpdesk, who tells them to close and reopen their mail client. > Maybe you're small enough to not run into problems, or maybe your users just > have lower expectations or a higher pain threshold than ours. Either way, > it's unpleasant for everyone involved, and quite easy to solve with the > director proxy. > > Timo has been saying for YEARS that you need user-node affinity if you're > doing NFS, and now he's done something about it. If you've already got a > load balancer, then just point the balancer at a pool of directors, and then > point the directors at your existing mailserver pool. > > > For health monitoring on the directors, check out: > http://github.com/brandond/poolmon > > > -Brad > > -- -- Ariel Biener e-mail: ar...@post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html
Re: [Dovecot] dovecot 1.0.15 upgrading to dovecot 1.1.x or 1.2.x, and POP3 UIDL issue
Ariel Biener wrote: Hi, I think I found the problem eventually: In the dovecot.conf example file, the section explaining the various UIDL formats is as follows: # If you want UIDL compatibility with other POP3 servers, use: # UW's ipop3d : %08Xv%08Xu # Courier : %f or %v-%u (both might be used simultaneosly) # Cyrus (<= 2.1.3): %u # Cyrus (>= 2.1.4): %v.%u # Dovecot v0.99.x : %v.%u # tpop3d : %Mf # # Note that Outlook 2003 seems to have problems with %v.%u format which was # Dovecot's default, so if you're building a new server it would be a good # idea to change this. %08Xu%08Xv should be pretty fail-safe. # #pop3_uidl_format = %08Xu%08Xv Notice that the UW format at the top is: %08Xv%08Xu , while at the bottom it is %08Xu%08Xv. So, in 1.0.15 we had it as the top would have it, while at the 1.1.x/1.2.x instances we just uncommented the bottom. I must have looked at these files 1000 times. --Ariel We're upgrading a cluster of servers from v1.0.15 to v1.1.x or v1.2.x. It appears that the UIDL generation mechanism has changed, and thus we'll be getting POP3 dups with users that leave mail on server (which is a nasty practice, I know). From checking the sources, and performing a number of controlled tests in various scenarios, here is the outcome: upgrade from 1.0.15 to 1.1.x (latest), UIDLs change (no change to the mail backend, that is, mbox) However, the interesting part is that if for example I read a mailbox for the first time with the 1.1.x version, and then I migrate the mailbox to a different server, running 1.1.x or 1.2.x, with Maildir or mailbox the UIDL does *NOT* change. We do not have X-UIDL headers in the mailboxes. I did every possible permutation of these tests. It appears that the way UIDLs are created in 1.0.x is different than what is used in 1.1.x and 1.2.x. (I am not talking about the format, we're using the same format in both, that is, UW compatible). Since we're a largish site (university), and we have some >60k accounts, even the smallest percentage of users who use POP3 and "leave mail on server" is a large number of angry staff members landing on our helpdesk, which is the reason why we're not migrating. Has anyone ever ported the UIDL generation algorithm from 1.0.x to 1.1.x/1.2.x to maintain compatibility ? Is there some other option that I am missing ? --Ariel
[Dovecot] dovecot 1.0.15 upgrading to dovecot 1.1.x or 1.2.x, and POP3 UIDL issue
Hi, We're upgrading a cluster of servers from v1.0.15 to v1.1.x or v1.2.x. It appears that the UIDL generation mechanism has changed, and thus we'll be getting POP3 dups with users that leave mail on server (which is a nasty practice, I know). From checking the sources, and performing a number of controlled tests in various scenarios, here is the outcome: upgrade from 1.0.15 to 1.1.x (latest), UIDLs change (no change to the mail backend, that is, mbox) However, the interesting part is that if for example I read a mailbox for the first time with the 1.1.x version, and then I migrate the mailbox to a different server, running 1.1.x or 1.2.x, with Maildir or mailbox the UIDL does *NOT* change. We do not have X-UIDL headers in the mailboxes. I did every possible permutation of these tests. It appears that the way UIDLs are created in 1.0.x is different than what is used in 1.1.x and 1.2.x. (I am not talking about the format, we're using the same format in both, that is, UW compatible). Since we're a largish site (university), and we have some >60k accounts, even the smallest percentage of users who use POP3 and "leave mail on server" is a large number of angry staff members landing on our helpdesk, which is the reason why we're not migrating. Has anyone ever ported the UIDL generation algorithm from 1.0.x to 1.1.x/1.2.x to maintain compatibility ? Is there some other option that I am missing ? --Ariel
