Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
We use ntpd daemon, all our systems are configured equal. Another thing, this is VM on vmware vsphere 4.1 Regards Maria - Original Message - From: Ed W Sent: 11/03/11 11:25 AM To: dovecot@dovecot.org Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube Hi We are running dovecot 2.0.13 with mdbox+zlib on RHEL 5.7 x64, ext4. We use NTP. Quick check, but by NTP you mean the background daemon and you don't have some cron job running ntpdate or similar every so often? No idea, but since it looks like a clock related curiousity, then knowing if the clock is spot on accurate or drifting would be interesting to know? Simple comparison against other machines over a similar period to you having problems might be accurate enough? Good luck Ed W
Re: [Dovecot] Imap/pop gateway
On 31/10/2011 22:20, nuno marques wrote: Hello, How can i make a imap/pop gateway? that is, putting the mailboxes on a server on the internal network and put the gateway in the dmz. The question isn't entirely clear, but I *think* you just want to use the normal proxy feature of dovecot. This accepts connections on one machine, examines them until the end of the auth stage and passes them onto some other machine based on the results of the auth process Also there are other imap/pop proxies such as nginx That said I'm not sure how much security this really buys you versus port forwarding POP/IMAP ports to your real server? If the proxy machine were to get hacked (over imap?) then the same hack can jump from the proxy to the real server. Also your only exposure in each case is via POP/IMAP, which means you would be mainly chasing buffer overflow vulnerabilities and the like. These can also be mitigated by chrooting the server machine (please consider virtualisation options, it's usually simpler/faster/saner, eg see my favourite: linux-vservers), MAC controls on the dovecot process (grsec/selinux, etc), and compiler extensions (gcc hardened) Good luck Ed W
Re: [Dovecot] Imap/pop gateway
If you are going to use an imap proxy for security reasons, consider using a software DIFFERENT than in your real mailboxes. If you use dovecot in your backend, you could use perdition in the frontend. Regards Maria - Original Message - From: Ed W Sent: 11/03/11 11:31 AM To: Dovecot Mailing List Subject: Re: [Dovecot] Imap/pop gateway On 31/10/2011 22:20, nuno marques wrote: Hello, How can i make a imap/pop gateway? that is, putting the mailboxes on a server on the internal network and put the gateway in the dmz. The question isn't entirely clear, but I *think* you just want to use the normal proxy feature of dovecot. This accepts connections on one machine, examines them until the end of the auth stage and passes them onto some other machine based on the results of the auth process Also there are other imap/pop proxies such as nginx That said I'm not sure how much security this really buys you versus port forwarding POP/IMAP ports to your real server? If the proxy machine were to get hacked (over imap?) then the same hack can jump from the proxy to the real server. Also your only exposure in each case is via POP/IMAP, which means you would be mainly chasing buffer overflow vulnerabilities and the like. These can also be mitigated by chrooting the server machine (please consider virtualisati on options, it's usually simpler/faster/saner, eg see my favourite: linux-vservers), MAC controls on the dovecot process (grsec/selinux, etc), and compiler extensions (gcc hardened) Good luck Ed W
Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
This could be the problem. Double check the time also on your host system(s), not only on guest. Bye, gc Il 03/11/2011 11.30, Maria Arrea ha scritto: We use ntpd daemon, all our systems are configured equal. Another thing, this is VM on vmware vsphere 4.1 Regards Maria - Original Message - From: Ed W Sent: 11/03/11 11:25 AM To: dovecot@dovecot.org Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube Hi We are running dovecot 2.0.13 with mdbox+zlib on RHEL 5.7 x64, ext4. We use NTP. Quick check, but by NTP you mean the background daemon and you don't have some cron job running ntpdate or similar every so often? No idea, but since it looks like a clock related curiousity, then knowing if the clock is spot on accurate or drifting would be interesting to know? Simple comparison against other machines over a similar period to you having problems might be accurate enough? Good luck Ed W -- Giulio Casella giulio at dsi.unimi.it System and network manager Computer Science Dept. - University of Milano
Re: [Dovecot] How can we horizontally scale Dovecot across multiple servers?
On 31/10/2011 11:28, Felipe Scarel wrote: Quick question about the usage of DRBD: I'm thinking of a setup on my organization here (15k+ users, 4TB of email data), but I'm holding back on the clusterization due to the high volume of data. Using DRBD would implicate mirroring those 4TB of data across all cluster nodes? If yes, I might go with a SAN-based solution, though I haven't I don't the technique with DRBD is something like having pairs of machines, each of which is a backup for the other. There were some old notes on the Dovecot website about such a setup? Roughly I seem to recall that each pair of machines ran two virtual machines, each of which ran active on one of the nodes each, but could migrate to the other if needed. Add a bunch of such paired nodes to get to the performance you require and put a dovecot proxy instance in front of the whole lot In contrast the SAN solution uses a clustered filesystem (opinion varies on which performs best) and then in theory every machine has access to every mailbox. In practice access to the SAN is relatively slow compared with local storage, so the technique seems to be to store indexes on the local machine and then using the front end proxy to be somewhat sticky in returning users to the same backend node so that the indexes can be re-used and not rebuilt The DRBD solution offers local disk access speed to the node and would on the surface give far faster performance (if disk were the limiting issue). However, it's likely to be more complex to maintain and manage and without buying licences you get only failover between pairs of machines. The SAN solution in theory looks like perfect scale up, big backend and just add more backend IMAP nodes as you need them, and all the clever stuff moves to the frontend load balancer to be sticky and obviously that's your main maintenance problem. However, based on evidence from users of big systems, IO is likely to be your main bottleneck and so just theoretically, the SAN will only scale as far as it doesn't run out of IOs... Using local disk for indexes would tend to reduce the amount of IOs needed (from the SAN) very dramatically, but you still have some limit out there and it's a question of whether you will reach it? DRBD has theoretical infinite scale out because each time you add another pair you get more IO as well as more CPU I don't have the fortune to have anything like the volume of users you have so I have no opinion to offer... However, I think the above accurately summarises your options. Others might help clarify the likely bounds on performance of each solution and maintenance headaches (eg some have had problems with maildir mounted on OCFS/GFS2 and fixed that by moving to dbox, etc) Please report on your results! Good luck Ed W
Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
All the ESXs hosts and all the VM use the same NTP server. Any other idea? Regards Maria - Original Message - From: Giulio Casella Sent: 11/03/11 11:38 AM To: dovecot@dovecot.org Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube This could be the problem. Double check the time also on your host system(s), not only on guest. Bye, gc Il 03/11/2011 11.30, Maria Arrea ha scritto: We use ntpd daemon, all our systems are configured equal. Another thing, this is VM on vmware vsphere 4.1 Regards Maria - Original Message - From: Ed W Sent: 11/03/11 11:25 AM To: dovecot@dovecot.org Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube Hi We are running dovecot 2.0.13 with mdbox+zlib on RHEL 5.7 x64, ext4. We use NTP. Quick check, but by NTP you mean the background daemon and you don't have some cron job running ntpdate or similar every so often? No idea, but since it looks like a clock related curiousity, then knowing if the clock is spot on accurate or drifting would be interesting to know? Simple comparison against other machines over a similar period to you having problems might be accurate enough? Good luck Ed W -- Giulio Casella giulio at ds i.unimi.it System and network manager Computer Science Dept. - University of Milano
Re: [Dovecot] patching dovecot for sieve/managesieve support, centos 5.6?
Op 3-11-2011 6:31, Scott Lewis schreef: 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'm not familiar with CentOS, but there usually is a separate package containing the Dovecot development headers and the dovecot-config file you need. By the looks of things, that is not installed at your end. Point the --with-dovecot to wherever the dovecot-config file is installed. Regards, Stephan.
Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
On 03/11/2011 10:49, Maria Arrea wrote: All the ESXs hosts and all the VM use the same NTP server. Any other idea? Doesn't ESX have issues with the time drifting when certain kernel options are set? Something to do with it rescheduling machines and them not counting idle ticks or something..? Does this problem happen during idle hours or peak hours? I should home in on clock problems... Probably vmware related issues to the kernel you are using? Good luck Ed W
Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
We follow the guidelines about timekeeping RHEL in vmware vsphere located here http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 These problems happens in peak hours. Any dovecot config parameter I could set to mitigate this problem? Regards Maria - Original Message - From: Ed W Sent: 11/03/11 11:57 AM To: Maria Arrea, Dovecot Mailing List Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube On 03/11/2011 10:49, Maria Arrea wrote: All the ESXs hosts and all the VM use the same NTP server. Any other idea? Doesn't ESX have issues with the time drifting when certain kernel options are set? Something to do with it rescheduling machines and them not counting idle ticks or something..? Does this problem happen during idle hours or peak hours? I should home in on clock problems... Probably vmware related issues to the kernel you are using? Good luck Ed W
Re: [Dovecot] Indexes to MLC-SSD
I'm using NexentaStor (Solaris, ZFS) to export iSCSI-LUNs and I was thinking about a SSD based LUN for the indexes. As I'm using multiple servers this LUN will use OCFS2. Given that the SAN always has the network latency behind it, might you be better to look at putting the SSDs in the frontend machines? Obviously this then needs some way to make users sticky to one machine (or some few machines) where the indexes are stored? This seems theoretically likely to give you higher IOPs to the index than having them on the OCFS2 storage? (At a trade off with more complexity for the load balancer front end...) Ed W
Re: [Dovecot] looking for Dovecot-code + SQL consultants
Hi, I've already received a number of replies from providers offering to help out. I'll be in touch with each, and am certain we'll be able to find the right solution from among them. Thanks for the responses, Rich On Tue, Nov 1, 2011 at 1:53 PM, Rich pgnet.dev+rich-dove...@gmail.com wrote: Hi, We're using Dovecot2. Trying, given our own spread-too-thin bandwidth, to make it work within our evolving SQL application environment. When there's a problem, we post to this list (e.g., http://www.dovecot.org/list/dovecot/2011-October/061609.html), but aren't getting any/timely responses. We've decided to look for a consultant (hourly or retainer) that can be available for working with our in-house staff to straighten these issues out -- by helping us identify fix our own mess, and by working to get fixes pushed to Dovecot project code, where appropriate. If you provide these services, rather than simply deployment or hosting, and are available, please drop me a line *offlist*. We're in the San Francisco area, and local is best, but remote work is certainly an option. Thanks, Rich
Re: [Dovecot] Indexes to MLC-SSD
Ed W schrieb: I'm using NexentaStor (Solaris, ZFS) to export iSCSI-LUNs and I was thinking about a SSD based LUN for the indexes. As I'm using multiple servers this LUN will use OCFS2. Given that the SAN always has the network latency behind it, might you be better to look at putting the SSDs in the frontend machines? Obviously this then needs some way to make users sticky to one machine (or some few machines) where the indexes are stored? Storing the indexes on several machines? In this case I have to synchronize them.
Re: [Dovecot] Indexes to MLC-SSD
Patrick Westenberg wrote: Ed W schrieb: I'm using NexentaStor (Solaris, ZFS) to export iSCSI-LUNs and I was thinking about a SSD based LUN for the indexes. As I'm using multiple servers this LUN will use OCFS2. Given that the SAN always has the network latency behind it, might you be better to look at putting the SSDs in the frontend machines? Obviously this then needs some way to make users sticky to one machine (or some few machines) where the indexes are stored? Storing the indexes on several machines? In this case I have to synchronize them. maybe i am missing something. if a client has to fetch the index, the server has to read the index from disk and pass it back. the network latency is unavoidable, but i don't see why putting the fastest possible SSD on the server isn't a win. possibly i am misunderstanding something?
[Dovecot] Restricting IMAP access
Hi list, I have a setup with postfix+dovecot+mysql unser CentOS 5, running 50 odd domains with virtual users. Access is allowed for public POP3, and a webmail on apache+PHP solution through local IMAP. I'm not gonna give you the long story about the why, but I'm looking for a way to give public IMAP access only to one domain, knowing that users log in with full email (u...@domain.tld). Anybody has a trick for that? Running dovecot 2.0.13. I know there should be a way to do it through the database, but quite heavy change on our side for a million odd users. Regards, Thierry
Re: [Dovecot] Indexes to MLC-SSD
Reasons to choose ZFS were snapshots, and mainly dedup and compression capabilities. I know, it's ironic since I'm not able to use them now due to severe performance issues with them (mostly dedup) turned on. I do like the emphasis on data integrity and fast on-the-fly configurability of ZFS to an extent, but I wouldn't recommend it highly for new users, especially for production. It works (in fact it's working right now), but has its fair share of troubles. We've started implementations to move our mail system to a more modular enviroment and we'll probably move away from ZFS. Was a nice experiment nonetheless, I learned quite a bit from it. On Thu, Nov 3, 2011 at 12:27, Ed W li...@wildgooses.com wrote: On 03/11/2011 11:32, Felipe Scarel wrote: I'm using native ZFS (http://zfsonlinux.org) on production here (15k+ users, over 2TB of mail data) with little issues. Dedup and compression disabled, mind that. OT: but what were the rough criteria that led you to using ZFS over say LVM with EXT4/XFS/btrfs? I can think of plenty for/against reasons for each, just wondering what criteria affected *your* situation? I'm guessing some kind of manageability reason is at the core, but perhaps you can expand on how it's all worked out for you? I have a fairly static server setup here so I have been satisfied with LVM, software raid and mainly ext4. The main thing I miss is simple to use snapshots Cheers Ed W
Re: [Dovecot] Restricting IMAP access
Am 03.11.2011 19:13, schrieb Thierry de Montaudry: Hi list, I have a setup with postfix+dovecot+mysql unser CentOS 5, running 50 odd domains with virtual users. Access is allowed for public POP3, and a webmail on apache+PHP solution through local IMAP. I'm not gonna give you the long story about the why, but I'm looking for a way to give public IMAP access only to one domain, knowing that users log in with full email (u...@domain.tld). Anybody has a trick for that? Running dovecot 2.0.13. I know there should be a way to do it through the database, but quite heavy change on our side for a million odd users. Regards, Thierry i am shot in time , with a databse this should be get to work i have it as flag for all users, so i can forbid imap to special ones as far i remember ther should be examples on the dovecot site , and it was written about here on the list before -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Difference between LOGIN and PLAIN
* Simon Brereton simon.brere...@buongiorno.com: Could someone explain to me the difference between LOGIN and PLAIN? In SMTP these are: Both - are plaintext mechanisms. - base64 encode identification data before they send it over the wire - do not encrypt the indentification data and should therefore only be offered over an encrypted transport layer PLAIN - is an open standard supported by most clients - sends identification data as one string - sends an authentication ID, an authorization ID and the password LOGIN - is a proprietary standard supported by Microsofts clients - sends LOGIN, login name, password and optionally the domain name one after another I guess they are basically the same in IMAP, but others will know better. p@rick I've been googling for a while, but haven't found anything. Thanks. Simon -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563
Re: [Dovecot] Difference between LOGIN and PLAIN
On 11/3/2011 9:42 PM, Simon Brereton wrote: Hi Could someone explain to me the difference between LOGIN and PLAIN? I've been googling for a while, but haven't found anything. The LOGIN SASL mechanism is an obsolete plain text mechanism. It is documented here: http://tools.ietf.org/html/draft-murchison-sasl-login-00 Some clients still support it, but I would not recommend using it when PLAIN or a better SASL mechanism is also available at both ends. The PLAIN mechanism is documented here: http://tools.ietf.org/html/rfc4616 The main technical difference between the two is that the PLAIN mechanism transfers both username and password in a single SASL interaction, where LOGIN needs two. The PLAIN mechanism also provides support for having an authorization id different from the authentication id, allowing for master user login for example. Regards, Stephan.
Re: [Dovecot] Difference between LOGIN and PLAIN
On Thu, 3 Nov 2011 16:42:40 -0400 Simon Brereton articulated: Hi Could someone explain to me the difference between LOGIN and PLAIN? I've been googling for a while, but haven't found anything. You could start here for some basic information: http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer http://wiki.dovecot.org/Authentication/Mechanisms -- Jerry ✌ dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] Difference between LOGIN and PLAIN
On 3 November 2011 17:01, Stephan Bosch step...@rename-it.nl wrote: On 11/3/2011 9:42 PM, Simon Brereton wrote: Hi Could someone explain to me the difference between LOGIN and PLAIN? I've been googling for a while, but haven't found anything. The LOGIN SASL mechanism is an obsolete plain text mechanism. It is documented here: http://tools.ietf.org/html/draft-murchison-sasl-login-00 Some clients still support it, but I would not recommend using it when PLAIN or a better SASL mechanism is also available at both ends. The PLAIN mechanism is documented here: http://tools.ietf.org/html/rfc4616 The main technical difference between the two is that the PLAIN mechanism transfers both username and password in a single SASL interaction, where LOGIN needs two. The PLAIN mechanism also provides support for having an authorization id different from the authentication id, allowing for master user login for example. Thanks to both of you. Can I bet that Outlook doesn't support anything but plain? I'm not sure I've ever heard of a client supporting other than Evolution supporting MD5 passwords.. Simon
