Re: [Dovecot] v1.1.rc7 released
v1.1 rc7 So far, so good, on OS X 10.5.3. No problems compiling, installing or running. :^) Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] How do I increase the fd limit on OS X?
On May 8, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote: Message: 6 Date: Wed, 7 May 2008 13:17:44 -0700 From: Rob Frohne <[EMAIL PROTECTED]> Subject: [Dovecot] How do I increase the fd limit on OS X? To: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain Hi All, I just upgraded to the new 1.1rc5 from 1.0 that I had been using and it advised me to increase the file descriptor limit. I'm not sure how to do this. There is a command built into tcsh that allows me to do this called limit, but sudo limit 4224 doesn't work, and usually dovecot is started from the rc.local file if I recall right, and I'm not sure how to set this up from there. Any advice. Thanks, Rob -- Rob Frohne <[EMAIL PROTECTED]> Walla Walla University Try this your_prompt_$ sudo sysctl -w kern.maxfiles=65536 your_prompt_$ sudo sysctl -w kern.maxfilesperproc=32768 You will be asked for your admin password. This will allow you to test things and see if it works better. The changes will revert to the system pre-defines when you re-boot or restart. IIRC, there is a master setting (unchangeable without recompiling OS X) that will not allow you to go over 65536, but I may be mistaken about that. For a permanent change, add the following lines to the /etc/sysctl.conf file: or the /etc/sysctl-macosxserver.conf file for Mac OS X Server You may have to create the file, especially if you are the only user. (Make sure that only root has access to this file!!) kern.maxfiles=65536 # System-wide limit kern.maxfilesperproc=32768 # Per-process limit This Is ONLY For OS X 10.3 or later. For earlier versions you need to use /etc/rc which was so long ago that I do not recall all of the commands (sorry). HTH, Jerry
Re: [Dovecot] Compiling with SSL
On Apr 22, 2008, at 5:00 AM, [EMAIL PROTECTED] wrote: (stuff cut out) Assuming that you have openssl installed and it is running okay, you can usually get this option included by using the LDFLAGS and CPPFLAGS For example: CPPFLAGS='-I/usr/local/include/openssl' LDFLAGS='-L/usr/local/lib -R/ usr/local/lib' \ ./configure \ --prefix=/usr/local \ --with-ssl=openssl \ --with-libiconv-prefix=/usr/local \ with the paths modified for your installation. HTH, Jerry -- Message: 6 Date: Tue, 22 Apr 2008 01:35:01 -0400 From: "Tom Ray [Lists]" <[EMAIL PROTECTED]> Subject: [Dovecot] Compiling with SSL To: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have Dovecot 1.0.9 running right now and I'm looking to upgrade but at the same time re-compile with SSL support. Dovecot's been working great for me so far. When I try to compile I keep getting this at the end: Building with SSL support ... : no Building with IPv6 support .. : yes Building with pop3 server ... : yes This is what my configure line looks like: ./configure --prefix=/usr/local/dovecot --with-pop3d --with- ssl=openssl --with-ssldir=/usr/local/vps/sharedssl/openssl --with-passwd-file Am I not doing something right? Am I reading the configuration setup wrong? Any help would be great! Thanks. snip
Re: [Dovecot] v1.1.beta15 released
On Feb 11, 2008, at 7:35 PM, [EMAIL PROTECTED] wrote: Message: 3 Date: Mon, 11 Feb 2008 22:03:08 +0200 From: Timo Sirainen <[EMAIL PROTECTED]> Subject: [Dovecot] v1.1.beta15 released To: Dovecot List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta15.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta15.tar.gz.sig It's been a while since the previous beta, so I guess it's time for a (Stuff cut out) This must be a day of updates. It works fine on the newly-released-today OS X 10.5.2 smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.1.beta14 released (Compile Error)
From the logs: Dovecot v1.1.beta14 starting up That did it. Thanks! Jerry p.s. I used the 'removing HAVE_POSIX_FALLOCATE from config.h' version. On Jan 20, 2008, at 1:01 PM, Timo Sirainen wrote: On 20.1.2008, at 19.40, Jerry Yeager wrote: Undefined symbols: "_posix_fallocate", referenced from: _file_set_size in liblib.a(file-set-size.o) Fixed: http://hg.dovecot.org/dovecot/rev/6c868e7fe7b2 You can also fix it by removing HAVE_POSIX_FALLOCATE from config.h smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.1.beta14 released (Compile Error)
On Jan 20, 2008, at 12:15 PM, [EMAIL PROTECTED] wrote: Message: 5 Date: Sun, 20 Jan 2008 15:48:09 +0200 From: Timo Sirainen <[EMAIL PROTECTED]> Subject: [Dovecot] v1.1.beta14 released To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta14.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta14.tar.gz.sig (stuff cut out) The new beta does not compile under OS X 10.5.1 It configures as usual, but then running the 'make' command gets to the point: mkdir .libs gcc -std=gnu99 (followed by the normal list of things it is going to build ) ending with ../lib/liblib.a /usr/local/lib/libiconv.dylib Undefined symbols: "_posix_fallocate", referenced from: _file_set_size in liblib.a(file-set-size.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [imap] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ??? Jerry -- ___ dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot End of dovecot Digest, Vol 57, Issue 60 *** smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master
Message: 8 Date: Tue, 15 Jan 2008 15:19:11 +0100 From: Andreas Ntaflos <[EMAIL PROTECTED]> Subject: Re: [Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="utf-8" On Tuesday 15 January 2008 03:56:28 Jerry Yeager wrote: while fiddling around with the configuration so Dovecot's LDA "deliver" can be used by multiple users by means of Getmail (you can read about that in [1]) I always end up running into the error message posted in the subject line: ( stuff snipped out ) One last thing, as a security idea, try something like master { path = /usr/local/var/run/dovecot/auth-master mode = 0600 user = dovecot_user group = dovecot_group } and set your postfix line that calls deliver to match: dovecot unix - n n - - pipe flags=DRhu user=dovecot_user:dovecot_group argv=/usr/local/libexec/dovecot/ deliver -f ${sender} -d ${recipient} Thanks for this suggestion! But that would imply that I have a virtual user setup, wouldn't it? Because I don't, all my users are regular Unix users with shell accounts. That's why my Postfix main.cf contains just home_mailbox = Maildir/ mailbox_command = /usr/local/libexec/dovecot/deliver which is also what the LDA/Postfix wiki page says on wiki.dovecot.org. No Dovecot entry in master.cf at all. Actually I was responding to what you had listed in your message i.e. socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 432 user: root group: dovecot -- which is a setup type you would use in a virtual style of user (either a "super user" or a group of non-system listed users with different uids / gids) setup . I had not encountered your other postings until later. Jerry And, as also mentioned elsewhere in this thread, until yesterday I didn't even have the master { ... } section uncommented, and no auth-master socket seems to have been configured. But then again I only delivered through Postfix and didn't need to have deliver called by a regular user. Andreas -- Andreas "daff" Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://dovecot.org/pipermail/dovecot/attachments/20080115/33439c1a/attachment.bin -- ___ dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot End of dovecot Digest, Vol 57, Issue 46 *** smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master
-- Message: 7 Date: Tue, 15 Jan 2008 00:21:02 +0100 From: Andreas Ntaflos <[EMAIL PROTECTED]> Subject: [Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hello list, while fiddling around with the configuration so Dovecot's LDA "deliver" can be used by multiple users by means of Getmail (you can read about that in [1]) I always end up running into the error message posted in the subject line: Jan 15 00:00:02 HOSTNAME deliver(USERID): Can't connect to auth server at /usr/local/var/run/dovecot/auth-master: Permission denied Notice how it says "/usr/local/var/run/dovecot"! How and why does dovecot ^^ think that anything of any importance can be found under /usr/local/ var/... ? Please see dovecot -n at the end of this message, but as far as I can tell I master: path: /var/run/dovecot/auth-master mode: 432 user: root group: dovecot -- Andreas "daff" Ntaflos Vienna, Austria For the quick answer to your immediate problem / question, try: cd /path/to/dovecot's/deliver (probably /usr/local/libexec/dovecot/ ) chmod u+s deliver (enable the setuid bit for the deliver app). Your Getmail app may not be truly running as root and thus does not really have permission to do what you want. you may need to do the same for the group as well Unix permissions are weird sometimes, like a $100 television tube that protects a 50 cent fuse by blowing first. It does look like (from your use of /usr/local/*) you built dovecot to run out of /usr/local. One last thing, as a security idea, try something like master { path = /usr/local/var/run/dovecot/auth-master mode = 0600 user = dovecot_user group = dovecot_group } and set your postfix line that calls deliver to match: dovecot unix - n n - - pipe flags=DRhu user=dovecot_user:dovecot_group argv=/usr/local/libexec/dovecot/ deliver -f ${sender} -d ${recipient} (try to have dovecot run as an unprivileged user as much as you can) smime.p7s Description: S/MIME cryptographic signature
[Dovecot] 1.1b13 build
After reading of the problems encountered on other systems, the 1.1 beta 13 version (main part as well as Deliver) seems to inexplicably be running just fine under OS X 10.5.1 for some reason. :^) Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.1.beta12 deliver crashes (arvids) Ditto!
On Dec 22, 2007, at 5:00 AM, [EMAIL PROTECTED] wrote: (stuff cut out) Message: 10 Date: Sat, 22 Dec 2007 11:12:30 +0200 From: arvids <[EMAIL PROTECTED]> Subject: [Dovecot] v1.1.beta12 deliver crashes To: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hello, v1.1.beta12 deliver crashes: Dec 22 11:05:29 iserver deliver(tests2): file index-mail.c: line 1042 (index_mail_close): assertion failed: (!mail- >data.destroying_stream) Dec 22 11:05:29 iserver deliver(tests2): Raw backtrace: /usr/local/ dovecot/libexec/dovecot/deliver(i_syslog_fatal_handler+0x2c) [0x80baa8c] -> /usr/local/do vecot/libexec/dovecot/deliver [0x80ba88b] -> /usr/local/dovecot/ libexec/dovecot/deliver [0x80852e1] -> /usr/local/dovecot/libexec/ dovecot/deliver(index_mail _free+0xe) [0x8085f5e] -> /usr/local/dovecot/libexec/dovecot/ deliver(mail_free+0x10) [0x80a9b70] -> /usr/local/dovecot/libexec/ dovecot/deliver(main+0xfce) [ 0x805a9be] -> /lib/libc.so.6(__libc_start_main+0xd8) [0xb7e69df8] - > /usr/local/dovecot/libexec/dovecot/deliver [0x8058a51] more stuff cut out Regards, Arvids -- I am getting essentially the same type of error, except that the message actually is delivered along with a receipt to the sender that it was not able to be delivered. Dec 22 11:33:57 mac-g5 deliver([EMAIL PROTECTED]) [28416]: msgid=<[EMAIL PROTECTED] >: saved mail to INBOX Dec 22 11:33:57 mac-g5 deliver([EMAIL PROTECTED]) [28416]: file index-mail.c: line 1042 (index_mail_close): assertion failed: (!mail->data.destroying_stream) Dec 22 11:33:57 mac-g5 deliver([EMAIL PROTECTED]) [28417]: auth input: [EMAIL PROTECTED] Dec 22 11:33:57 mac-g5 deliver([EMAIL PROTECTED]) [28416]: Raw backtrace: 2 deliver 0x000c8ae4 i_syslog_fatal_handler + 124 -> 3 deliver 0x000c8598 i_fatal + 0 -> 4 deliver 0x00057f5c index_mail_close + 264 -> 5 deliver 0x00058958 index_mail_free + 68 -> 6 deliver 0x000a406c mail_free + 68 - > 7 deliver 0x55d8 main + 4344 -> 8 deliver 0x10d0 start + 68 Dec 22 11:33:58 mac-g5 postfix/pipe[28415]: 251EE4D094C: to=<[EMAIL PROTECTED] >, relay=dovecot, delay=0.38, delays=0.02/0.04/0/0.32, dsn=5.3.0, status=bounced (Command died with signal 6: "/usr/local/libexec/ dovecot/deliver") Dec 22 11:33:58 jerry-yeagers-power-mac-g5 postfix/qmgr[67]: 251EE4D094C: removed Switching to using the Postfix deliver works and it seems everything else in the new beta 12, so far, is fine. Running on OS X 10.5.1 Jerry smime.p7s Description: S/MIME cryptographic signature
[Dovecot] Fishing attempt locking up dovecot
On Dec 11, 2007, at 5:58 PM, [EMAIL PROTECTED] wrote: Message: 10 Date: Tue, 11 Dec 2007 15:58:16 -0700 From: Patrick Milvich <[EMAIL PROTECTED]> Subject: [Dovecot] Fishing attempt locking up dovecot To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes I've mentioned this before but only heard from one other person who has experienced this, but it's becoming a pretty serious issue. The situation: A spammer sets a bot on a fishing attempt to gain email addresses, causing numerous login processes to spawn and suck up all available resources. The problem: Obviously this can act like a dos attack, but the real issue is after the spammer stops (by virtue of being added to our firewall blacklist, being caught and shut down by their isp, or otherwise), dovecot doesn't seem to relinquish the resources, causing "too many files open" errors for normal usage. stuff cut out End of dovecot Digest, Vol 56, Issue 33 *** Will the following be of any help to you? (it is a patch for Postfix 2.4.nn) It would seem that the type of fishing expedition you mention would fall into the bit described below (lots of errors). While it will not directly solve the "out of resources" Dovecot problem, it may limit the up-front damage, followed with a CRON script running every twenty minutes or so that scans the last line of the mail log for the 'too many files open' error and upon finding it runs a version of the killall imap-login processes. ftp://postfix.mirrors.pair.com/index.html Postfix 2.4 patch (PGP signature ) to add stress-adaptive behavior to the SMTP server. When some mail flood keeps all server ports busy, this feature can be used to quickly drop connections from clients that make errors, and to reduce the time that Postfix waits for a client command. This may delay some legitimate deliveries, but it will allow you to still keep some mail flowing. After the mail flood ends, Postfix reverts to its normal behavior. smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.1.beta11 released (Problems) now Fixed
On Dec 10, 2007, at 8:59 AM, Timo Sirainen wrote: On 9.12.2007, at 23.27, Jerry Yeager wrote: Dec 9 16:03:50 ns1 dovecot[331]: imap-login: We couldn't drop root group privileges (wanted=150, gid=150, egid=0) I wondered a bit if this change would break anything, but since it worked with Linux I thought it would work elsewhere too. This fixes it: http://hg.dovecot.org/dovecot/rev/d7a48bf83a0e Thanks Timo, that did fix the problem (and overall things seem to be a bit faster). So, v1.1 beta 11 is now running on OS X 10.5 and OS X 10.4. Jerry smime.p7s Description: S/MIME cryptographic signature
[Dovecot] v1.1.beta11 released (Problems)
On Dec 9, 2007, at 1:48 PM, [EMAIL PROTECTED] wrote: Message: 7 Date: Sun, 09 Dec 2007 20:29:49 +0200 From: Timo Sirainen <[EMAIL PROTECTED]> Subject: [Dovecot] v1.1.beta11 released To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta11.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta11.tar.gz.sig This one should be the last beta release before the first v1.1 release candidate. I'll try to stay away from this list and Dovecot in general for the next 1,5 weeks. I've several exams coming up and I should have started studying for them days ago already.. :) stuff cut out End of dovecot Digest, Vol 56, Issue 26 *** I ran into a problem moving from v 1.1 beta 10 to v 1.1 beta 11, the logs show: Dec 9 16:03:49 ns1 dovecot[331]: Dovecot v1.1.beta11 starting up Dec 9 16:03:50 ns1 dovecot[331]: imap-login: We couldn't drop root group privileges (wanted=150, gid=150, egid=0) Dec 9 16:03:50 ns1 dovecot[331]: Temporary failure in creating login processes, slowing down for now The last two messages then begin repeating until Dovecot is shut down. obviously, no one can log in. I tried changing the following # System user and group used to access mails. If you use multiple, userdb # can override these by returning uid or gid fields. You can use either numbers # or names. #mail_uid = #mail_gid = to explicitly specifying # System user and group used to access mails. If you use multiple, userdb # can override these by returning uid or gid fields. You can use either numbers # or names. mail_uid = Dovecot mail_gid = Dovecot As well as setting the setuid bit in login_executable = /usr/local/libexec/dovecot/imap-login to no avail. Dropping back to v 1.1 beta 10 fixed things for the moment. I did a quick scan of the example conf file and the wiki docs but could not find anything relevant. dovecot -n shows (essentially the same for both versions) # 1.1.beta11: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imaps ssl_listen: *:993 ssl_cipher_list: ALL:!LOW:!SSLv2 verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_user: Dovecot login_greeting: Hello, Dovecot is ready. valid_chroot_dirs: /var/mail/vmail/ mail_extra_groups: mail mail_location: maildir:/var/spool/vmail/%d/%n:INDEX=/var/spool/vmail/ %d/%n:INBOX=/var/spool/vmail/%d/%n mail_debug: yes lock_method: flock auth default: mechanisms: plain login passdb: driver: passwd-file args: scheme=plain-md5 username_format=%u /etc/dovecot/passwd userdb: driver: static args: uid=virtual gid=virtual home=/var/spool/vmail/%d/%n socket: type: listen client: path: /var/spool/postfix/private/auth user: postfix group: postfix master: path: /usr/local/var/run/dovecot/auth-master user: virtual group: virtual This is running on OS X 10.5.1 ??? Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] SPAM: Re: 1.1beta9 'make' fails on osx/Tiger
On Nov 28, 2007, at 5:51 PM, snowcrash wrote: p.s. The folks at AT&T also recommend that "you" use the newer version of gcc than the older-hacked-to-get-something-for-Tiger version of the Apple Leopard version they (AT&T) are providing -- it is further down the page where they provide links. just looked at the page & have no idea what you're referring to ... can you quote? thx. http://r.research.att.com/tools/ It begins with Building a universal compiler Note: This section is now becoming obsolete given Apple's gcc 42 branch, but it is kept here until we have more definite information on Apple's Fortran support. . .. ... ... skipping down to ... ... .. . get gcc sources This is obviuos, you clearly need gcc sources. One way to get them is via svn, for example: svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch gcc-4.2 Leopard has svn built in, there are open source clients available for Tiger. If you do not like using svn to get your stuff, just hit the main gcc.gnu.org site and follow the links to grab the gzipped file. Since this is really drifting away from Dovecot, the rest of the folks on the list might prefer to take the correspondence off the list. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger
On Nov 28, 2007, at 1:39 PM, [EMAIL PROTECTED] wrote: -- Message: 7 Date: Wed, 28 Nov 2007 10:38:19 -0800 From: snowcrash <[EMAIL PROTECTED]> Subject: Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger To: "Jerry Yeager" <[EMAIL PROTECTED]> Cc: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 (stuff cut out) i'd gather tss would like to know about issues. (it shouldn't be terribly surprising for a projects' beta release to at least be _tried_ with _other_ projects' beta releases ...) cheers. That is usually a good idea, especially if you mention that you are using non standard stuff so that folks who are not aware of that can then get a better understanding of the issues. Or for the elucidation of the folks that are following the list trying to decide what efforts they will have to undertake to make the switch. p.s. The folks at AT&T also recommend that "you" use the newer version of gcc than the older-hacked-to-get-something-for-Tiger version of the Apple Leopard version they (AT&T) are providing -- it is further down the page where they provide links. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger (Not Really)
On Nov 28, 2007, at 10:59 AM, [EMAIL PROTECTED] wrote: Message: 8 Date: Wed, 28 Nov 2007 07:49:13 -0800 From: snowcrash <[EMAIL PROTECTED]> Subject: Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create) To: "Timo Sirainen" <[EMAIL PROTECTED]> Cc: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 (lots of messages from the digest snipped out) Actually, the 1.1 beta v9 builds just fine under Tiger (PPC and PPC64) if you use the official Apple sanctioned gcc v 4.01 they ship with both Tiger and Leopard. If you do download and use gcc 4.2.1 from the GNU folks you might want to pass along the error / bug reports to them instead of Apple, but I suspect the GNU folks will tell you to try the current 4.2.2 version or the new 4.3 version. Jerry smime.p7s Description: S/MIME cryptographic signature
[Dovecot] Version 1.1beta 6 and OS X Leopard (10.5)
Just a quick note: The new 1.1-b6 is working fine on OS X 10.5. smime.p7s Description: S/MIME cryptographic signature
[Dovecot] Dovecot] Postfix and Dovecot Deliver LDA
On Nov 2, 2007, at 9:48 AM, [EMAIL PROTECTED] wrote: -- Message: 4 Date: Fri, 02 Nov 2007 13:00:56 +0100 From: spammy <[EMAIL PROTECTED]> Subject: [Dovecot] Postfix and Dovecot Deliver LDA To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, Having problems moving from postfix/dovecot/mysq/maildrop existing intall to dovecot LDA dovecot -n stuff chomped out deliver([EMAIL PROTECTED]): 2007-11-02 12:32:40 Info: auth input: gid=5000 deliver([EMAIL PROTECTED]): 2007-11-02 12:32:40 Fatal: setuid(5000) failed: Operation not permitted I'm using vmail:vmail (5000:5000) for all my virtual users and postfix (snipped some more out) roger Hello Roger, Try this: cd to the path where the dovecot deliver app is. Then, sudo chmod u+s deliver You may or may not need to do sudo chmod g+s deliver -- probably not. This is in the Sendmail - LDA part of the docs. Recent changes to Dovecot seem to have brought this to Postfix - LDA as well. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] Squirrelmail with 1.1 Beta 3
On Oct 16, 2007, at 6:05 PM, [EMAIL PROTECTED] wrote: (various messages snipped) -- Message: 8 Date: Tue, 16 Oct 2007 12:14:04 -0700 From: Bill Landry <[EMAIL PROTECTED]> Subject: Re: [Dovecot] Squirrelmail Problem with 1.1 Beta 3 To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Jeff Grossman wrote: I just installed 1.1 beta 3 and noticed a problem when sending an e-mail with Squirrelmail. When I hit send, I get the following error in my log: Oct 16 11:35:54 apple dovecot: IMAP(jeff): Disconnected: EOF while appending bytes=1851/5926 Oct 16 11:35:54 apple imapproxyd[9132]: Raw_Proxy(): IMAP server unexpectedly closed the connection on sd 9 I am also using imapproxy. I wasn't sure if that line would help also. In Squirrelmail I get a LOGOUT message when it tries to redisplay the INBOX listing. The message does get sent correctly, but it does not get copied to my Sent Items folder. I went and deleted all of the dovecot.index* files and now I don't get that error anymore, but I now get the following error. The message is now copied to the Sent Items folder. Oct 16 11:44:45 apple dovecot: IMAP(jeff): Cache file /home/jeff/.maildir/.Sent Items/dovecot.index.cache: Newly added field got lost unexpectedly Same here, using Dovecot 1.1 Beta 3 and SquirrelMail 1.4.10a-1.fc7. SquirrelMail with either Firefox 2.0.0.7 or IE 6.0.2900.2180 browser sessions: It works okay using the new Squirrel Mail 1.4.11 with Safari as well as as Firefox and Opera on OS X. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] How to upgrade a running Dovecot?
On Oct 5, 2007, at 12:41 PM, [EMAIL PROTECTED] wrote: -- Message: 1 Date: Fri, 5 Oct 2007 10:25:49 +0100 From: Mike Brudenell <[EMAIL PROTECTED]> Subject: Re: [Dovecot] How to upgrade a running Dovecot? To: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Jerry/et al - Hello Mike, (stuff chomped out) Scenario 2: Altered SSL Certificates = I need to replace our current certificates and have prepared new files containing the replacement certificate and private key. Am I right in thinking that I can simply modify dovecot.conf to point at the new files and send a HUP signal to dovecot? Specifically, will new connections use the revised certificates, and existing connections continue to work OK without interruption? Ehh not really, the auth child processes can be killed and new ones started. See your next scenario question. ...So here you're saying that although the "dovecot" master process re-reads the configuration file, it doing so has no effect on the existing authenticator child processes? And is it these processes that are dealing with the SSL connection? ... I'd have thought it was either the "imap-login" or "imap" processes? Just to be clear about this for myself, (instead of relying on the 'ol saying 'that is how it used to work' -- because I am switching over to 1.1 from 1.0.n your question takes on new relevance for me as well) I tested this and yes it works as before, the new files seem to be used for the new connections (all of the dovecot auth processes are killed on the HUP signal -- dovecot itself just rereads the conf file and new auth listeners are started -- assuming that you use Dovecot for the auth mechanism to Postfix) and existing connections seem to handle things okay. I did find something new (or I have not noticed it before) If you kill (not just restart) the Dovecot process itself and restart it with existing connections (someone was connected to IMAPS when you killed Dovecot) Dovecot will not restart, complaining that port 993 is taken already. This happens regardless of the shutdown_clients = yes/no setting. This may be particular to the new version 1.1, I do not know. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] How to upgrade a running Dovecot?
Have you considered sending out a message to each user to the effect that on some day, darned-early a.m. the system will be offline for 30 minutes for maintenance (no incoming email will be lost, etc., etc.). Message: 3 Date: Thu, 4 Oct 2007 13:57:03 +0100 From: Mike Brudenell <[EMAIL PROTECTED]> Subject: [Dovecot] How to upgrade a running Dovecot? To: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Greetings - Could someone confirm how to perform various upgrades on a live system running Dovecot please? Scenario 1: Change to dovecot.conf === If I make a change to dovecot.conf am I right in thinking I can simply send a HUP signal to the main dovecot process to get it to re- read the configuration file and act on its revised content? Yes, this is correct. Scenario 2: Altered SSL Certificates = I need to replace our current certificates and have prepared new files containing the replacement certificate and private key. Am I right in thinking that I can simply modify dovecot.conf to point at the new files and send a HUP signal to dovecot? Specifically, will new connections use the revised certificates, and existing connections continue to work OK without interruption? Ehh not really, the auth child processes can be killed and new ones started. See your next scenario question. Scenario 3: Software Upgrade = I build a particular version of Dovecot into the tree /usr/local/ dovecot-A.B.C and then have a symlink called "dovecot" pointing at the this directory. To upgrade I can then build the new version into /usr/local/dovecot-X.Y.Z and test. To actually switch over the live service to the new X.Y.Z version do I need to: a) Totally shut down the old A.B.C version of Dovecot, thereby breaking all open connections for users? or b) Assuming I am using "shutdown_clients = no" can I just kill the master "dovecot" process and then start up the new version? See the preface, do the update when you typically have few folks using the system -- which gives you fewer complaints from users should things break on their end. Ideally I want existing connections to remain running, but new connections to start up using the new X.Y.Z version of Dovecot. The comment for "shutdown_clients" implies this, but also says: "This however means that after master process has died, the client processes can't write to log files anymore." So if I understand this correctly then with "shutdown_clients = no" in force then the sequence and behaviour is this? ... 1. Old version A.B.C of Dovecot running, clients can log through the master "dovecot" process to the logfiles. 2. Kill the old master "dovecot" process, start new X.Y.Z version up. 3. New connections get served by version X.Y.Z. Old connections DON'T get killed and can continue, BUT can no longer write anything to the logfiles? With many thanks, Mike B-) -- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740 * Unsolicited commercial e-mail is NOT welcome at this e-mail address. * smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.0 vs 1.1b re: Postfix and Dovecot LDA
From: Bill Cole <[EMAIL PROTECTED]> (stuff cut out) That looks like a bug. A program that calls setgroups() must be running as root. It seems to me that a code path leading to such a call should probably be able to identify that issue before the call and provide a better failure message than translating EPERM into its standard meaning The interesting question would be: why does deliver want to call setgroups() at all? I am not sure why it would need to do this either. It (deliver) is not handing things off to another app to finish things up. I'd love to take credit, but I thought that was about the LDA with Sendmail, which is rather different, and Rich was running 1.0.3... In any event, I won't go so far as to say that running deliver as setuid root is actively dangerous, but it feels wrong to me and I wouldn't do it. That may be from too much exposure to bizarre attacks through delivery agents in the Dark Ages. That it works without being setuid on Linux is a touch odd. The mystery deepens! I have it (deliver) in a restricted access folder as a standard safety precaution, but as most of these "jails" end up being only safe for a short time I have again gone back to using Postfix as the deliver. Timo has from time to time mentioned that he was thinking that deliver needed to be rewritten. hmmm. I still give you and Rich credit though, if you had not mentioned the ideas behind Sendmail and LDA, it would most likely taken much longer before I read that wiki entry and gave that approach a try, instead of trying to find the missing setting for changing groups that the error message wants fixed. -- Bill Cole [EMAIL PROTECTED] -- Message: 7 Date: Thu, 27 Sep 2007 17:07:28 -1000 (HST) From: Julian Cowley <[EMAIL PROTECTED]> Subject: [Dovecot] Dovecot raw backtrace when copying to folder To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Seeing a problem with a certain user causing dovecot to crash when copying mail to a folder. This looks similar to a bug someone on the mailing list posted recently. Since the backtrace mentions the index, I tried deleting all of the index files for the user (including subfolders) but it had no effect. Seems that the bug still happens when creating the index for the first time. Unfortunately, I can't pin down if there is a particular message causing the problem but I'll see if I can track it using strace. Lines are broken for clarity. This is dovecot 1.0.5 on CentOS 4.5. Sep 27 16:41:42 cookie dovecot: imap-login: Login: user=<[EMAIL PROTECTED]>, method=PLAIN, rip=:::xx.xx.xx.xx, lip=:::yy.yy.yy.yy, TLS Sep 27 16:41:53 cookie dovecot: IMAP([EMAIL PROTECTED]): Trying to allocate 0 bytes Sep 27 16:41:53 cookie dovecot: IMAP([EMAIL PROTECTED]): Raw backtrace: imap [0x80ad7d4] -> imap [0x80ad239] -> imap [0x80b5624] -> imap(i_malloc+0x1b) [0x80b0e1b] -> imap [0x8083037] -> imap [0x80833e6] -> imap(index_storage_search_init+0xf4) [0x80836f4] -> imap(cmd_copy+0x145) [0x8056d15] -> imap(cmd_uid+0x7c) [0x805a74c] -> imap [0x805b2d5] -> imap [0x805b25e] -> imap(_client_input+0x8c) [0x805b43c] -> imap(io_loop_handler_run+0x169) [0x80b3e09] -> imap(io_loop_run+0x28) [0x80b3178] -> imap(main+0x49f) [0x806384f] -> /lib/tls/libc.so.6(__libc_start_main+0xd3) [0x506de3] -> imap [0x8055db1] Sep 27 16:41:53 cookie dovecot: child 26079 (imap) killed with signal 6 -- ___ dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot End of dovecot Digest, Vol 53, Issue 77 *** smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.0 vs 1.1b re: Postfix and Dovecot LDA
On Sep 27, 2007, at 2:55 AM, Lars Stavholm wrote: We're runnng dovecot 1.1beta1 and /.../dovecot/deliver is owned by root and has only rwxr-xr-x, No problems so far. /L I wonder if this is an OS specific issue... which OS are you using? smime.p7s Description: S/MIME cryptographic signature
[Dovecot] v1.0 vs 1.1b re: Postfix and Dovecot LDA
In running the various 1.0.n versions of Dovecot's LDA with the instructions in the wiki for using LDA with Postfix [on OS X 10.4] things went well using the instructions as-is (no setuid problems). This changed in moving over to the 1.1 beta. The LDA refused to work failing with the error "setgroups() failed: Operation not permitted" as I mentioned in a previous message. After reading the exchange between Bill Cole and Rich Winkel and following up on this, it seems that the new 1.1b wants you to give the Deliver app specific setuid permission via: cd /path/to/where/dovecot's/deliver/is sudo chmod u+s deliver Then things worked as before. There was no need to give the group 's' permission nor to change ownership of deliver from the default root:staff or root:wheel or whomever... . The error message seems odd though. I am not sure if, overall, this means there is a problem in Dovecot 1.0.n or that things are being tightened up in 1.1b. Thanks Bill and Rich for the tip! Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.1.beta1 released
On Sep 23, 2007, at 11:23 AM, [EMAIL PROTECTED] wrote: Re: v1.1.beta1 released So far every thing is up and running well, (OS X 10.4 on a G5 machine). There are two things: From the logs: 1) dovecot: fd limit 256 is lower than what Dovecot can use under full load (more than 1152). Either grow the limit or change login_max_processes_count and max_mail_processes settings this is of course NOT a dovecot problem, it is just being nice and saying it can use more than the OS X defaults for open files. The next come from using the new Dovecot LDA: in trying to send mail, the following error occurs and I have not been able to find the setting to change this 2) postfix/qmgr[25767]: 2459A37F612: from=, size=1226, nrcpt=1 (queue active) deliver(to-email-address): auth input: to-email-address deliver(to-email-address): auth input: uid=1000 deliver(to-email-address): auth input: gid=1000 deliver(to-email-address): auth input: home=path/to/ deliver(to-email-address): setgroups() failed: Operation not permitted postfix/pipe[6505]: 2459A37F612: to=, relay=dovecot, delay=984, delays=984/0.03/0/0.06, dsn=4.3.0, status=deferred (temporary failure) The solution so far is to go back to using the Postfix Deliver option. Where is the setgroups option being set in the LDA? Thank for you hard work!! Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
[Dovecot] (re: B. Baca 2) Dovecot] Unexpected input from auth master: CUID
Also check the top of Authentication processes section: ## ## Authentication processes ## # Executable location auth_executable = /path/to/libexec/dovecot/dovecot-auth smime.p7s Description: S/MIME cryptographic signature
[Dovecot] (re: B. Baca) Dovecot] Unexpected input from auth master: CUID
Branislav Baca wrote the following: Hello, I'm using postfix(2.4.5) and dovecot(1.0.5), and till now I have been using postfix deliver agent. Now I have tried to reconfigure postfix to use the dovecot LDA, but I'm getting some strange error: Try this: socket listen { master { path = /path/to/run/dovecot/auth-master mode = 0600 user = your_dovecot_user_name group = your_dovecot_user_name } client { path = /path/to/postfix/private/auth mode = 0660 user = your_postfix_user_name group = your_postfix_group_name } } protocol lda { postmaster_address = [EMAIL PROTECTED] mail_plugin_dir = /path/to/lib/dovecot/lda sendmail_path = /usr/sbin/sendmail <-- this is the usual postfix path to sendmail auth_socket_path = /path/to/run/dovecot/auth-master } smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] deliver assertion failure
On Aug 15, 2007, at 5:00 PM, [EMAIL PROTECTED] wrote: Message: 7 Date: Thu, 16 Aug 2007 08:59:25 +1200 From: Jasper Bryant-Greene <[EMAIL PROTECTED]> Subject: [Dovecot] deliver assertion failure To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii Deliver from latest 1.1 HG with sieve also from latest 1.1 HG is dying with an assertion failure when it delivers to my mailbox. Other mailboxes on the same system are unaffected, but I can read my mailbox fine through IMAP. Dovecot and sieve were compiled with -march=nocona -pipe -ggdb I've commented out my entire sieve script and the problem still occurs. file index-mail-headers.c: line 590 (index_mail_get_raw_headers): assertion failed: (ret != -1) - Last output repeated twice - Raw backtrace: /usr/libexec/dovecot/deliver(i_syslog_panic_handler+0x2b) [0x493125] -> /usr/libexec/dovecot/deliver(i_fatal+0) [0x492b17] -> /usr/libexec/dovecot/deliver [0x44f7cf] -> /usr/libexec/dovecot/deliver(index_mail_get_first_header+0x30) [0x44fb9b] -> /usr/libexec/dovecot/deliver(mail_get_first_header+0x3a) [0x47ca3d] -> /usr/libexec/dovecot/deliver(deliver_get_return_address+0x21) [0x41453b] -> /usr/lib/dovecot/lda/lib90_cmusieve_plugin.so(cmu_sieve_run +0x14b) [0x2b3687f194a1] -> /usr/lib/dovecot/lda/lib90_cmusieve_plugin.so [0x2b3687f169ba] -> /usr/libexec/dovecot/deliver(main+0x8dc) [0x415c4d] -> /lib/libc.so.6(__libc_start_main+0xe3) [0x2b3687cf6533] -> /usr/libexec/dovecot/deliver [0x4137a9] Jasper -- ___ dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot End of dovecot Digest, Vol 52, Issue 56 *** I am getting the same error, the mail is still being delivered, but the system is generating an error message sent to the original sender The mail system : Command died with signal 11: "/usr/local/libexec/dovecot/deliver" Reporting-MTA: dns; HIDDEN X-Postfix-Queue-ID: 7F344239D31 X-Postfix-Sender: rfc822; EMAIL ADDRESS HIDDEN Arrival-Date: Wed, 15 Aug 2007 15:53:32 -0400 (EDT) Final-Recipient: rfc822; EMAIL ADDRESS HIDDEN Action: failed Status: 5.3.0 Diagnostic-Code: x-unix; internal software error the mail logs show: to=, relay=dovecot, delay=1.5, delays=0.01/0.02/0/1.5, dsn=5.3.0, status=bounced (Command died with signal 11: "/usr/local/libexec/dovecot/deliver") This did not happenr in v1.1 alpha 2, but is now appearing in 1.1 alpha 1.3 after a day or so of using the new version. Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] use of deliver from procmail advisable?
On Aug 15, 2007, at 5:00 PM, [EMAIL PROTECTED] wrote: -- Message: 3 Date: Wed, 15 Aug 2007 18:08:58 +0200 From: martin f krafft <[EMAIL PROTECTED]> Subject: Re: [Dovecot] use of deliver from procmail advisable? To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="utf-8" also sprach Jerry Yeager <[EMAIL PROTECTED]> [2007.08.15.1758 +0200]: a) Postfix milter to run ClamAv, eh something like this (for Linux fans) b) then use the regular Postfix <--> SpamAssassin <--> LDA (with sieve) setup (message routing via Postfix master.cf) so that individual users can set their own SA rules and vacation stuff. This is exactly how I used to have it but then the need for a vacation autoresponse to the From: address (as opposed to Return-Path) arose and I had to switch to procmail: http://dovecot.org/list/dovecot/2007-August/024766.html Before that, I was using spamc with --pipe-to, but always had a bad feeling about that, since the manpage says: Note that there is a very slight chance mail will be lost here, because if the fork-and-exec fails there?s no place to put the mail message. and my message to SA-users on this was never answered[0]. 0. http://marc.info/?l=spamassassin-users&m=115185095923772&w=2 Now I am using procmail and at least now that failure will cause postfix to defer a message. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] half a bee, philosophically, must ipso facto half not be. but half the bee has got to be, vis-a-vis its entity. you see? but can a bee be said to be or not to be an entire bee, when half the bee is not a bee, due to some ancient injury? -- monty python spamtraps: [EMAIL PROTECTED] -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) Url : http://dovecot.org/pipermail/dovecot/attachments/ 20070815/96f09f99/attachment-0001.bin -- Ouch, that does pose a bit more of a problem. Putting an additional case type structure in Sieve to use the From: field along with either dropping back to the current reply-path or gracefully do not reply for messages from those folks that use a web-mailer without filling in the from: field, then recompiling Sieve would do it, but you really would not be gaining a lot over what you currently have. Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] use of deliver from procmail advisable?
On Aug 15, 2007, at 5:00 AM, [EMAIL PROTECTED] wrote: Message: 7 Date: Wed, 15 Aug 2007 00:58:40 +0200 From: martin f krafft <[EMAIL PROTECTED]> Subject: Re: [Dovecot] use of deliver from procmail advisable? To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" also sprach Charles Marcus <[EMAIL PROTECTED]> [2007.08.14.2028 +0200]: Well, the whole point of sieve, I believe, is to make it something that an admin would want to let arbitrary users modify on their own recognizance, and the ability to specify arbitrary programs to run would be just *asking* to be hacked. Wouldn't a decent, secure alternative to procmail be sieve+amavisd- new? Except it's not really possible to make amavisd-new do per-user spam filtering. And it's even more of a performance hog. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] "all language designers are arrogant. goes with the territory..." -- larry wall spamtraps: [EMAIL PROTECTED] -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) Url : http://dovecot.org/pipermail/dovecot/attachments/ 20070815/3d429306/attachment-0001.bin -- It is true that amavis-new does over-ride or otherwise seemingly discard some but not all of the individual user configuration options from SpamAssassin, but have you considered trying the following? a) Postfix milter to run ClamAv, eh something like this (for Linux fans) http://wiki.linuxquestions.org/wiki/Postfix_with_clamav-milter It is a bit dated, so double check the docs over at the Postfix site to take advantage of updates to the milter abilities in Postfix. b) then use the regular Postfix <--> SpamAssassin <--> LDA (with sieve) setup (message routing via Postfix master.cf) so that individual users can set their own SA rules and vacation stuff. Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] dovecot Digest, Vol 52, Issue 52
From the digest: On Aug 14, 2007, at 1:04 PM, [EMAIL PROTECTED] wrote: other messages cut out… Message: 9 Date: Tue, 14 Aug 2007 19:03:58 +0200 From: martin f krafft <[EMAIL PROTECTED]> Subject: Re: [Dovecot] use of deliver from procmail advisable? To: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" also sprach Kyle Wheeler <[EMAIL PROTECTED]> [2007.08.14.1833 +0200]: I understand that dovecot's deliver does a little more than deliver: It also understands the 'seive' filter language (an alternative to procmail). I don't consider it an alternative to procmail because you cannot pass mail to external programmes, like spamassassin or vacation. Sure, sieve has its own vacation module, but I find that to be rather limited. See this thread: http://dovecot.org/list/dovecot/2007-August/024686.html What do you think will be less resource-heavy: calling deliver for every mail received *in addition to* procmail, or letting the IMAP server update the metadata on access? Unless you're cutting it close to the limit on what your server can handle, that's probably the wrong question to ask. A better question is: which gives my users better performance? Good point. The users, however, as far as I know, all use tools like offlineimap to synchronise in the background, so it hardly matters. your users aren't paying attention. Dovecot will *seem* snappier if you do the indexing work on delivery rather than on access, even though it may spend more CPU cycles overall to do so. Does anyone have hard facts on how much the server process loses if it encounters a folder with an index inconsistency? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] mulutlitithtrhreeaadededd s siigngnatatuurere spamtraps: [EMAIL PROTECTED] -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) Url : http://dovecot.org/pipermail/dovecot/attachments/20070814/ a1ee49ad/attachment.bin -- End of dovecot Digest, Vol 52, Issue 52 *** I am trying to understand if you mean that Sieve does not play well with other apps or if you mean it is Dovecot's LDA that does not play well, 'cuz the LDA works quite well with SpamAssassin via Postfix's and Dovecot's virtual user setup… Here is a portion of the Postfix Master.cf file that let it work (non- relevant portions chopped out) smtp inet n - n - - smtpd -o content_filter=spamassassin virtual unix - n n - - virtual tlsmgrunix - - n 1000? 1 tlsmgr 587 inet n - - - - smtpd -o content_filter=spamassassin dovecot unix - n n - - pipe flags=DRhu user=virtual:virtual argv=/usr/local/libexec/dovecot/ deliver -f ${sender} -d ${recipient} spamassassin unix - n n - - pipe user=nobody argv=/usr/local/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient} The header from this actual message (so you can see it in action -- note the email address are obscured) From: HIDDEN Subject:dovecot Digest, Vol 52, Issue 52 Date: August 14, 2007 1:04:06 PM EDT To: HIDDEN Reply-To: HIDDEN Return-Path: Delivered-To: HIDDEN Received: by mail.HIDDEN (Postfix, from userid -2) id 0F11A234567; Tue, 14 Aug 2007 13:04:55 -0400 (EDT) Received: from HIDDEN (HIDDEN [A.B.C.D]) by mail.HIDDEN (Postfix) with ESMTP id 41ED223455C for ; Tue, 14 Aug 2007 13:04:48 -0400 (EDT) Received: from HIDDEN (localhost.localdomain [127.0.0.1]) by HIDDEN (Postfix) with ESMTP id BA3101647268 for ; Tue, 14 Aug 2007 20:04:45 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on HIDDEN.local X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS autolearn=ham version=3.2.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Beenthere:HIDDEN X-Mailman-Version: 2.1.9 Precedence: list List-Id:Dovecot Mailing List List-Unsubscribe: , <mailto:HIDDEN?subject=unsubscribe> List-Archive: List-Post: List-Help: List-Subscribe: , Sender: HIDDEN Errors-To: HIDDEN Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] Version 1.1 Alpha 2 Various Stuff
On Aug 9, 2007, at 9:28 AM, Timo Sirainen wrote: On Wed, 2007-08-08 at 17:36 -0400, Jerry Yeager wrote: dovecot: imap-login: Maximum number of connections exceeded: user=, method=PLAIN, rip=192.168.1.1, lip=192.168.1.50, TLS mail_max_userip_connections limit causes this. I guess I'll have to change the error message, because even I thought it was something completely different. Changing this setting did the trick, so to speak. Mulberry v 4.0.6 is now working with the new Alpha 2 release. Thank you for your help! Jerry Yeager smime.p7s Description: S/MIME cryptographic signature
[Dovecot] Version 1.1 Alpha 2 Various Stuff
Some preamble information… OS X 10.4.10 (all updates) Power Mac Dual G5, 2.0 Postfix with Dovecot SASL, Dovecot LDA, Dovecot imaps (openssl) Mail clients Apple Mail v 2.1 SquirrelMail v 1.4.10a Thunderbird v 2.0.0.6 Mulberry v 4.06 For various versions of Dovecot, from 0.9m up through 1.0.3 things went well, no memorable big problems, with one exception: Mulberry v 4.0.8 would/will not work; i.e. it refuse(d) to connect saying it could not start SSL to begin the connection. Dropped back to version 4.0.6. I switched to version 1.1 alpha 2 (compile and configuration information is attached at the end of this message) 1) Started up Apple mail. Mail boxes disappeared in Apple Mail's list, except for the main Inbox mail box. Fixed by setting mailbox_list_index_disable = yes in the Dovecot.conf file, restarted both Dovecot and Mail, all the mailboxes reappeared and worked correctly. 2) Started up Squirrel Mail using several different browsers. No problems. 3) Started up Thunderbird. No problems. 4) Started up Mulberry. It partially connected, but stopped with the error saying that it had hit the limit for maximum connections. Mail logs show: dovecot: imap-login: Maximum number of connections exceeded: user=, method=PLAIN, rip=192.168.1.1, lip=192.168.1.50, TLS I tried increasing the various limits in the Dovecot.conf file up through a maximum limit of 2048 connections, to no avail. Mulberry will initially connect to several of the mailboxes, but will stop without getting all of them and will throw up the 'over the connection limit' error and will then show you a dialog box that asks you to log-in. Attempting to doing so returns a fatal error 54. I have not tried Mulberry's version 4.0.8. 5) Mail logs had this message suddenly begin appearing: auth-worker(default): pam(username,192.168.1.1): pam_authenticate() failed: Authentication failure Fixed by completely commenting PAM authentication section out; It was: passdb pam { # [blocking=yes] [session=yes] [setcred=yes] # [cache_key=] [] # ... essentially a placeholder section, since everything inside is commented out # # } now is: #passdb pam { # # ... even the outer block is commented out # #} The error has now disappeared from the logs. Dovecot was build using: CPPFLAGS=-I/usr/local/include/openssl LDFLAGS='-L/usr/local/lib -R/ usr/local/lib' \ ./configure \ --with-ssl=openssl \ --with-libiconv-prefix=/usr/local Dovecot.conf: # 1.1.alpha2: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imaps ssl_listen: *:993 ssl_parameters_regenerate: 24 ssl_cipher_list: ALL:!LOW:!SSLv2 verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_user: Dovecot login_greeting: Hello, Dovecot is ready. valid_chroot_dirs: /var/mail/vmail/ mail_extra_groups: mail mail_location: maildir:/var/spool/vmail/%d/%n:INDEX=/var/spool/vmail/% d/%n:INBOX=/var/spool/vmail/%d/%n mail_debug: yes mailbox_list_index_disable: yes lock_method: flock imap_client_workarounds: delay-newmail auth default: mechanisms: plain login passdb: driver: passwd-file args: /etc/dovecot/passwd userdb: driver: passwd-file args: /etc/dovecot/users socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /usr/local/var/run/dovecot/auth-master mode: 384 user: virtual group: virtual smime.p7s Description: S/MIME cryptographic signature