Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
Hi Jeff, Did you try play with imap_client_workarounds options? I think this must help you: outlook-idle: Outlook and Outlook Express never abort IDLE command, so if no mail arrives in half a hour, Dovecot closes the connection. This is still fine, except Outlook doesn't connect back so you don't see if new mail arrives. Wednesday, August 1, 2007, 3:12:17 AM, you wrote: I have been using Dovecot for an IMAP server for a few years now, with no hitch. Even using Outlook 2K/2K3 as a client. Yesterday, I had a user experience the 'Negative UIDs' issue spoken of here: http://wiki.dovecot.org/Clients/NegativeUIDs I performed all of the steps mentioned in this article, and it seemed like it would work properly the first time the user checked their email, and then after that, they would get this error again. I checked to see what the latest stable version of Dovecot was, and decided to upgrade. I was at 0.99.11-8 and the latest stable rpm for my distro was 1.0.2-2. The upgrade went fine. Or so I thought. I am now getting the following message on all Outlook Clients: Your IMAP Server closed the connectionthis can occur if the connection is idle for too long I have scoured the Internet for this error and have come up with many suggestions, none of which have worked. I have increased Outlook's timeout period to the full 10 minutes, and I have disabled SELinux. None of this seems to have worked. Is there anyone out there who has actually had this issue and resolved it? Can you please help? Thanks, Jeff Ramsey MIS Administrator TMI Forest Products, Inc. [EMAIL PROTECTED] 360.477.0738 -- Sergey
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On Tue, 2007-07-31 at 17:12 -0700, Jeff Ramsey wrote: I am now getting the following message on all Outlook Clients: Your IMAP Server closed the connectionthis can occur if the connection is idle for too long What does Dovecot show in logs as the disconnect reason? This sounds like the IDLE problem that outlook-idle workaround avoids, but that's the default so I'd think you haven't disabled it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] IMAPs and POP3s poxying
On Fri, 2007-07-27 at 09:10 -0400, Jason Russler wrote: How would I configure Dovecot to proxy another single system without doing the SQL look-up? Dovecot isn't really designed for that kind of a proxying, so you can't avoid it. Is there a port-forwarding solution that would work better (for POP3s and IMAPS)? These are RedHat 5 hosts so Netfilter is fair game if the protocols allow. Thanks, Well, it sounds like you need generic TCP proxying which doesn't need to know about the used protocol at all. Googleing tcp proxy found this as the first hit: http://nest.cs.uiowa.edu/22C178f00/article/12.html signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
version: 1.0.2 imap_client_workarounds = outlook-idle And I've no problem with OE 6.0. I've been testing with imap since I read your first post, and there have not been any disconnections. I don't know about OE2003. /Bachman Sergey A. Kobzar skrev: Hi Jeff, Did you try play with imap_client_workarounds options? I think this must help you: outlook-idle: Outlook and Outlook Express never abort IDLE command, so if no mail arrives in half a hour, Dovecot closes the connection. This is still fine, except Outlook doesn't connect back so you don't see if new mail arrives. Wednesday, August 1, 2007, 3:12:17 AM, you wrote: I have been using Dovecot for an IMAP server for a few years now, with no hitch. Even using Outlook 2K/2K3 as a client. Yesterday, I had a user experience the 'Negative UIDs' issue spoken of here: http://wiki.dovecot.org/Clients/NegativeUIDs I performed all of the steps mentioned in this article, and it seemed like it would work properly the first time the user checked their email, and then after that, they would get this error again. I checked to see what the latest stable version of Dovecot was, and decided to upgrade. I was at 0.99.11-8 and the latest stable rpm for my distro was 1.0.2-2. The upgrade went fine. Or so I thought. I am now getting the following message on all Outlook Clients: Your IMAP Server closed the connectionthis can occur if the connection is idle for too long I have scoured the Internet for this error and have come up with many suggestions, none of which have worked. I have increased Outlook's timeout period to the full 10 minutes, and I have disabled SELinux. None of this seems to have worked. Is there anyone out there who has actually had this issue and resolved it? Can you please help? Thanks, Jeff Ramsey MIS Administrator TMI Forest Products, Inc. [EMAIL PROTECTED] 360.477.0738
Re: [Dovecot] dovecot-auth core dumps
On Mon, 2007-07-30 at 14:06 -0600, Cassidy B. Larson wrote: gdb /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot- auth.core This looks correct. (gdb) bt full #0 0x180abc22 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x08059246 in mech_deinit () No symbol table info available. #2 0x08053f12 in auth_request_handler_unref () No symbol table info available. #3 0x08050bef in auth_client_connection_destroy () No symbol table info available. #4 0x08050ead in auth_client_connection_create () No symbol table info available. #5 0x08065f54 in io_loop_handler_run () No symbol table info available. #6 0x08065605 in io_loop_run () No symbol table info available. #7 0x0805722a in main () No symbol table info available. But this looks broken unfortunately. Usually it happens if the core file wasn't created by the exact same binary you gave to gdb. One way to be sure would be to attach gdb to dovecot-auth while it's still running: gdb /usr/local/libexec/dovecot/dovecot-auth pid of dovecot-auth continue wait for crash bt full Also your dovecot-auth doesn't contain debugging information. It would be helpful to have that (make install probably strips them), but maybe not required if I just can get a nonbroken backtrace. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] IMAP-Proxy and LDAP?
On Mon, 2007-07-30 at 22:59 +0200, Patrick Ben Koetter wrote: I am doing some research on Dovecots IMAP-Proxy features mentioned in http://wiki.dovecot.org/HowTo/ImapProxy and http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy. The docs only mention SQL as backend to hold required data. Is it also possible to use LDAP? Sure, if you can return the needed fields from LDAP. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] apparent bug with filesystem quota and message lists
On Mon, 2007-07-30 at 11:34 -0400, Stewart Dean wrote: When users go over quota, when they login the next time, the folder list is blank. I don't see why this would happen. Listing mailboxes doesn't try to write anything to filesystem. Can you try this yourself by making an account over quota and then trying what LIST command shows? 1 login user pass 2 list * 3 lsub * Although if the client tries to always SUBSCRIBE to mailboxes, even if they already are, then Dovecot probably fails. But it should log an error then. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve discard
On Aug 1, 2007, at 6:29 AM, Timo Sirainen wrote: Since the last changes for http://hg.dovecot.org/dovecot-sieve-1.0/ are: Added tag 1.0.2 for changeset 0afb958e7e71 Released v1.0.2. There isn't really anything to be released as v1.0.3. :) Timo, This comment still remains in the dovecot-sieve INSTALL... It's also not a good idea to build the plugin against self-compiled Dovecot sources, but then actually use a prebuilt binary package of Dovecot. That might work if the Dovecot versions are the same, but it's not guaranteed. Being a Mac System, I've ALWAYS built dovecot-sieve against self- compiled Dovecot sources and have never had an issue with sieve (that others also haven't had.) So maybe that comment is no longer required? (For me, it's just confusing :-)) Thanks, B. Bodger
Re: [Dovecot] [Dovecot-news] v1.0.3 released
On Wed, Aug 01, 2007 at 01:22:59PM +0300, Timo Sirainen wrote: http://dovecot.org/releases/1.0/dovecot-1.0.3.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.3.tar.gz.sig No dovecot-sieve-1.0.3 tarball (yet)? Geert
Re: [Dovecot] [Dovecot-news] v1.0.3 released
On Wed, 2007-08-01 at 13:04 +0200, Geert Hendrickx wrote: On Wed, Aug 01, 2007 at 01:22:59PM +0300, Timo Sirainen wrote: http://dovecot.org/releases/1.0/dovecot-1.0.3.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.3.tar.gz.sig No dovecot-sieve-1.0.3 tarball (yet)? 1.0.2 works just fine with it. The version numbers just have happened to be the same earlier. signature.asc Description: This is a digitally signed message part
[Dovecot] Missing MIME-Version header in e-mails.
Hi, I notice that in src/lib-mail/message-parser.c, there is a section of code that checks for the presence of MIME-Version before allowing processing of the Content-* headers. Is there a possibility of relaxing this rule? There are some broken mailers, in particular newsletter mailers that do not seem to honour the MIME-Version header, though they do send the Content-Type. Cheers.
[Dovecot] Mount options and NFS: just checking...
Greetings - I'm now in the last couple of weeks before going live with Dovecot (v1.0.3) on our revamped IMAP service. I'd like to double-check about the best mount options to use; could someone advise, please? I have three separate directory trees for the message store, the control files and the index files. These are arranged as follows: Message Store Mounted over NFS from a NetApp filer; filestore quotas are ENABLED. Control Files Mounted over NFS from the NetApp filer; filestore quotas are DISABLED. Index Files Mounted on local disk; filestore quotas are DISABLED. We will have a pair of Solaris 10 servers on which Dovecot 1.0.3 is running. Users are normally directed to their preferred server but, if it is unavailable, will go via the other server. Q1. Am I right in thinking that for the Message Store and Control Files I should NFS-mount both of them with the actimeo=0? (Or would noac be better, which also turns off client write- caching as well as the attribute cache?) Q2. Should I NFS-mount either or both of the Message Store and Control Files with the noxattr option to turn off extended attributes? Q3. Which of the filestores should I mount with the noatime option? (I understand that for the filer-based NFS mounts this can be done on the filer, as the option isn't available with mount for NFS-monted filestores.) Q4. Any other options to use/miss out? Currently my understanding from the list and the NFS page at the Wiki is: A1. Use actimeo=0 for both Message Store and Control Files. No idea about the need for/impact of using noac. A2. No idea. A3. Safe to use noatime for all three filestores. (I understand Dovecot will use utime() when needed on such filestores, but am not sure if it will work on the NFS-mounted filestores from the filer if access times are turned off at the filer end.) Any thoughts, please? Cheers, 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. *
Re: [Dovecot] sieve discard
On Wed, 2007-08-01 at 06:51 -0400, Bruce Bodger wrote: This comment still remains in the dovecot-sieve INSTALL... It's also not a good idea to build the plugin against self-compiled Dovecot sources, but then actually use a prebuilt binary package of Dovecot. That might work if the Dovecot versions are the same, but it's not guaranteed. Being a Mac System, I've ALWAYS built dovecot-sieve against self- compiled Dovecot sources and have never had an issue with sieve (that others also haven't had.) So maybe that comment is no longer required? (For me, it's just confusing :-)) I guess I could change might work - most likely works. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Mount options and NFS: just checking...
On Wed, 2007-08-01 at 12:54 +0100, Mike Brudenell wrote: We will have a pair of Solaris 10 servers on which Dovecot 1.0.3 is running. Users are normally directed to their preferred server but, if it is unavailable, will go via the other server. Q1. Am I right in thinking that for the Message Store and Control Files I should NFS-mount both of them with the actimeo=0? Since files in message store don't change, actimeo=0 isn't really needed, although if other servers are adding mails to maildirs then it does make noticing new mails faster. For control files actimeo=0 is needed for now. (Or would noac be better, which also turns off client write- caching as well as the attribute cache?) If you're not using fsync_disable then write caching shouldn't be a problem. Q2. Should I NFS-mount either or both of the Message Store and Control Files with the noxattr option to turn off extended attributes? No idea. Dovecot doesn't use them, so I don't think it breaks anything, but does it give any benefits? Q3. Which of the filestores should I mount with the noatime option? A3. Safe to use noatime for all three filestores. (I understand Dovecot will use utime() when needed on such filestores, but am not sure if it will work on the NFS-mounted filestores from the filer if access times are turned off at the filer end.) If your kernel caches atime updates locally, then maybe you shouldn't use noatime for message store until v1.1. It doesn't cause real problems, but Dovecot wastes time looking for old files in tmp/ directories all the time. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] [Dovecot-news] v1.0.3 released
On Wed, Aug 01, 2007 at 02:41:44PM +0300, Timo Sirainen wrote: 1.0.2 works just fine with it. The version numbers just have happened to be the same earlier. Is this documented somewhere? Or how do we know which dovecot-sieve version matches which dovecot version(s)? I thought they always had to be the same... Otherwise you could just create dovecot-sieve-1.0.3.tar.gz as a symlink to dovecot-sieve-1.0.2.tar.gz... Geert
Re: [Dovecot] sieve discard
On Wed, 2007-08-01 at 14:46 +0300, Timo Sirainen wrote: On Wed, 2007-08-01 at 06:51 -0400, Bruce Bodger wrote: This comment still remains in the dovecot-sieve INSTALL... It's also not a good idea to build the plugin against self-compiled Dovecot sources, but then actually use a prebuilt binary package of Dovecot. That might work if the Dovecot versions are the same, but it's not guaranteed. Being a Mac System, I've ALWAYS built dovecot-sieve against self- compiled Dovecot sources and have never had an issue with sieve (that others also haven't had.) So maybe that comment is no longer required? (For me, it's just confusing :-)) I guess I could change might work - most likely works. Or I guess since this hasn't been a problem normally I could just remove it unless it becomes a common problem. Updated the text: Use --with-dovecot=path to point to dovecot-config file's directory. There are two possibilities where this could exist: 1) If you configured Dovecot with --enable-header-install, you'll have dovecot-config installed in $prefix/lib/dovecot/ directory. 2) Compiled Dovecot sources' root directory. So for example: ./configure --with-dovecot=/usr/local/lib/dovecot make sudo make install sievec and sieved binaries are built only if you use 2) method, because they need to link with Dovecot's libraries. They can be used to compile and decompile Sieve scripts. You probably don't need these. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve discard
On Wed, Aug 01, 2007 at 03:02:38PM +0300, Timo Sirainen wrote: Or I guess since this hasn't been a problem normally I could just remove it unless it becomes a common problem. Updated the text: Use --with-dovecot=path to point to dovecot-config file's directory. There are two possibilities where this could exist: 1) If you configured Dovecot with --enable-header-install, you'll have dovecot-config installed in $prefix/lib/dovecot/ directory. 2) Compiled Dovecot sources' root directory. So for example: ./configure --with-dovecot=/usr/local/lib/dovecot make sudo make install sievec and sieved binaries are built only if you use 2) method, because they need to link with Dovecot's libraries. They can be used to compile and decompile Sieve scripts. You probably don't need these. (1) is very interesting from a packager's point of view (allows me to package dovecot-sieve for pkgsrc much easier), but e.g. pysieved (the python managesieve server) needs sievec for verifying sieve scripts while uploading... Geert
Re: [Dovecot] Mount options and NFS: just checking...
Hi, Timo - On 1 Aug 2007, at 13:14, Timo Sirainen wrote: Q3. Which of the filestores should I mount with the noatime option? A3. Safe to use noatime for all three filestores. (I understand Dovecot will use utime() when needed on such filestores, but am not sure if it will work on the NFS-mounted filestores from the filer if access times are turned off at the filer end.) If your kernel caches atime updates locally, then maybe you shouldn't use noatime for message store until v1.1. It doesn't cause real problems, but Dovecot wastes time looking for old files in tmp/ directories all the time. Many thanks! I think I'm nearly there now: could you just clarify on the items flagged with (??) below? In case it makes a difference, messages will generally be delivered by a user's preferred IMAP server, but by Exim rather than Dovecot's deliver. actimeo=0 option NFS-mounted Message Store: NOT needed, but if used can help spot new messages more quickly NFS-mounted Control Files: REQUIRED for now Local Index Files: Not applicable noatime option NFS-mounted Message Store: Probably OK to use, but safer not to until v1.1 NFS-mounted Control Files: Can be used safely(??) (Or as above??) Local Index Files: Can be used safely(??) 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. *
Re: [Dovecot] mbox bug in 1.0.0
On Jun 19 2007, [EMAIL PROTECTED] wrote: On May 13 2007, Timo Sirainen wrote: On Mon, 2007-04-23 at 13:40 -0500, [EMAIL PROTECTED] wrote: Apr 23 13:22:41 server.umn.edu dovecot: [ID 107833 local6.error] [9073] IMAP(USER): mbox /var/mail/user: seq=1 uid=8808 uid_broken=0 originally needed 10 bytes, now needs 23 bytes Anything else than Dovecot accessing these mboxes (besides MDA)? Nope. Dovecot IMAP and deliver. Do you have a core file from that crash? It would show a bit more information. If not, see http://dovecot.org/bugreport.html So, I'm including a backtrace for this. Sorry if you replied earlier and I missed it! Please let me know what else you might need. We're seeing this on about three dozen inboxes (which is a very small percentage, but a large enough number to hear about it :) ). (dbx) where [1] 0xff1c16e8(0x6, 0x0, 0xff1a4d28, 0x, 0xff1e8298, 0x6), at 0xff1c16e8 [2] _getutxline(0x9d8b0, 0x1, 0xb00e0, 0xa8244, 0xff1eb298, 0x0), at 0xff140158 =[3] i_internal_panic_handler(fmt = 0x93b88 mbox %s: seq=%u uid=%u uid_broken=%d originally needed %llu bytes, now needs %u bytes, args = 0xffbfe7d0), line 403 in failures.c [4] i_panic(format = 0x93b88 mbox %s: seq=%u uid=%u uid_broken=%d originally needed %llu bytes, now needs %u bytes, ...), line 183 in failures.c [5] mbox_sync_rewrite(sync_ctx = 0xffbfefd0, mail_ctx = (nil), end_offset = 4448ULL, move_diff = 30LL, extra_space = 4294971774ULL, first_seq = 1U, last_seq = 163U), line 422 in mbox-sync-rewrite.c [6] mbox_sync_do(sync_ctx = 0xffbfefd0, flags = -4198952), line 920 in mbox-sync.c [7] mbox_sync(mbox = 0xc99e0, flags = MBOX_SYNC_UNDIRTY), line 1873 in mbox-sync.c [8] mbox_storage_sync_init(box = 0xc99e0, flags = MAILBOX_SYNC_FLAG_FULL_READ), line 1957 in mbox-sync.c [9] mailbox_sync_init(box = 0xc99e0, flags = MAILBOX_SYNC_FLAG_FULL_READ), line 406 in mail-storage.c [10] imap_sync_nonselected(box = 0xc99e0, flags = MAILBOX_SYNC_FLAG_FULL_READ), line 196 in imap-sync.c [11] _cmd_select_full(cmd = 0xc39e4, readonly = 0), line 39 in cmd-select.c [12] cmd_select(cmd = 0xc39e4), line 92 in cmd-select.c [13] client_handle_input(cmd = 0xc39e4), line 335 in client.c [14] client_handle_input(cmd = 0xc39e4), line 389 in client.c [15] _client_input(context = 0xc39a0), line 432 in client.c [16] io_loop_handler_run(ioloop = 0xb9f08), line 199 in ioloop-poll.c [17] io_loop_run(ioloop = 0xb9f08), line 326 in ioloop.c [18] main(argc = -4195453, argv = 0xb0800, envp = 0xb1be4), line 290 in main.c And in case it helps, a dump from frame [5] which is the last bit before the crash: (dbx) frame 5 Current function is mbox_sync_rewrite 422 i_panic(mbox %s: seq=%u uid=%u uid_broken=%d (dbx) dump first_nonexpunged = 255U move_diff = 30LL ret = 0 mails = 0xcd810 idx = 0 padding_per_mail = 20U first_nonexpunged_idx = 0 expunged_space = 0 sync_ctx = 0xffbfefd0 extra_space = 4294971774ULL mail_ctx = (nil) dest_offset = 0 count = 2U last_seq = 163U orig_prev_msg_uid = 1359U next_move_diff = 10ULL end_offset = 4448ULL __PRETTY_FUNCTION__ = mbox_sync_rewrite start_offset = 0 offset = 4294971774ULL first_seq = 1U next_end_offset = 52ULL If these happen frequently, I could also send a debug patch that writes the broken mbox headers to some temp file. That with the core file would provide enough information to figure out what exactly is the problem. This is still an option, if it would help. -Brian Hayden Internet Services University of MN
Re: [Dovecot] Missing MIME-Version header in e-mails.
On Wed, 2007-08-01 at 19:50 +0800, Tan Shao Yi wrote: Hi, I notice that in src/lib-mail/message-parser.c, there is a section of code that checks for the presence of MIME-Version before allowing processing of the Content-* headers. Is there a possibility of relaxing this rule? There are some broken mailers, in particular newsletter mailers that do not seem to honour the MIME-Version header, though they do send the Content-Type. I suppose this could be changed. At least UW-IMAP also does that.. signature.asc Description: This is a digitally signed message part
[Dovecot] mbox inbox default
HI Timo all. We're an mbox environment, inboxes in /var/mail/$USER (I'll include dovecot -n output at the bottom of this mail). mail_location is set accordingly for deliver. I'd assumed that if the /var/mail/$USER file doesn't exist, dovecot would create it, but we've discovered from experience (and I verified it in mbox-storage.c) that if access(path, R_OK|W_OK) fails--as it does if the file doesn't exist--that dovecot defaults then to delivering in root_dir/inbox. I'm curious why this is. It seems like if the configured INBOX file doesn't exist, dovecot should create it if possible; it's a different case than if, say, the user doesn't have write access to that directory, in which case it of course would be appropriate to fall back to some other location rather than rejecting mail. Is there something I'm missing that makes my idea wrong? Thanks, -Brian Hayden OIT Internet Services University of MN # ./dovecot -n # /etc/opt/dovecot/dovecot.conf syslog_facility: local6 protocols: imap imaps pop3 pop3s listen(default): *:143 listen(imap): *:143 listen(pop3): *:110 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(pop3): *:995 ssl_cert_file: /etc/opt/openssl/certs/dovecot.pem ssl_key_file: /etc/opt/openssl/private/dovecot.pem shutdown_clients: no login_dir: /var/opt/dovecot/run/dovecot/login login_executable(default): /opt/dovecot/libexec/dovecot/imap-login login_executable(imap): /opt/dovecot/libexec/dovecot/imap-login login_executable(pop3): /opt/dovecot/libexec/dovecot/pop3-login login_log_format_elements: user=%u pid=%p method=%m rip=%r lip=%l %c login_processes_count: 32 login_max_processes_count: 6000 max_mail_processes: 8192 first_valid_uid: 100 mail_location: mbox:~:INBOX=/var/mail/%u:INDEX=/var/mail/.dovecot-index/%1u/%u/ mail_debug: yes mbox_lazy_writes: no mail_executable(default): /opt/dovecot/libexec/dovecot/mail_path.sh mail_executable(imap): /opt/dovecot/libexec/dovecot/mail_path.sh mail_executable(pop3): /opt/dovecot/libexec/dovecot/pop3 mail_plugins(default): acl mail_plugins(imap): acl mail_plugins(pop3): mail_plugin_dir(default): /opt/dovecot/lib/dovecot/imap mail_plugin_dir(imap): /opt/dovecot/lib/dovecot/imap mail_plugin_dir(pop3): /opt/dovecot/lib/dovecot/pop3 mail_log_prefix: [%p] %Us(%u): mail_log_max_lines_per_sec: 0 imap_client_workarounds(default): delay-newmail outlook-idle tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail outlook-idle tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv namespace: type: private separator: / location: mbox:~:INBOX=/var/mail/%u:INDEX=/var/mail/.dovecot-index/%1u/%u/ inbox: yes namespace: type: private separator: / prefix: mail/ location: mbox:~/mail/:INDEX=/var/mail/.dovecot-index/%1u/%u/ hidden: yes namespace: type: private separator: / prefix: ~/mail/ location: mbox:~/mail/:INDEX=/var/mail/.dovecot-index/%1u/%u/ hidden: yes namespace: type: private separator: / prefix: ~%u/mail/ location: mbox:~/mail/:INDEX=/var/mail/.dovecot-index/%1u/%u/ hidden: yes namespace: type: private separator: / prefix: Shared/ location: maildir:~/Maildir/Shared/:INDEX=/var/mail/.dovecot-index/%1u/%u/shared:CONTROL=/var/mail/.dovecot-index/%1u/%u/shared-control auth default: username_format: %Lu passdb: driver: pam args: session=yes * userdb: driver: passwd plugin: acl: vfile:
Re: [Dovecot] High cpu usage OpenSolaris
On Wed, 2007-08-01 at 15:12 +0200, DINH Viêt Hoà wrote: On 8/1/07, Timo Sirainen [EMAIL PROTECTED] wrote: On Sun, 2007-07-29 at 21:27 -0400, Gary Gendel wrote: All, Nevermind... I discovered the problem. It was in the Solaris Sun Studio 12 compiler. I created a debug version to begin testing, but that version worked without sucking up the cpu. So it looks like the optimizer messed up. If I used the -fast optimization, it sucks up cpu, but with -xO5 all is well. I heard about this before too. Would be nice to know if it really is a bug in Sun Studio or if the problem is caused by something done wrong in Dovecot's code. can't you use dtrace or something to know where the CPU time will go ? Last I heard it was that poll() was called all the time with zero (or 1ms?) timeout. So the problem is probably in src/lib/ioloop.c io_loop_get_wait_time() getting optimized wrong. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2
On Tuesday 31 July 2007 01:41:11 Stephan Bosch wrote: Have fun testing the patch. Notify me when there are problems. Hello Stephan, I still get the following message when trying to connect and authenticate: Choose a different authentication method to PLAIN. The same with LOGIN when I tell Dovecot to use the login authentication method. The logs show: Aug 1 15:25:52 hostname dovecot: managesieve-login: Login: user=username, method=PLAIN, rip=aa.bb.cc.dd, lip=ww.xx.yy.zz, TLS Aug 1 15:25:52 hostname dovecot: MANAGESIEVE(username): Disconnected: Logged out I am using real Unix users and Dovecot is configured with authdb pam and userdb passwd. I previously described the problem in [1]. Does your patch not support PLAIN or LOGIN or am I missing something? TIA Andreas [1] http://www.dovecot.org/list/dovecot/2007-June/023283.html -- Andreas daff Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] Mount options and NFS: just checking...
On Wed, 2007-08-01 at 14:19 +0100, Mike Brudenell wrote: In case it makes a difference, messages will generally be delivered by a user's preferred IMAP server, but by Exim rather than Dovecot's deliver. actimeo=0 option NFS-mounted Message Store: NOT needed, but if used can help spot new messages more quickly If only preferred server delivers mails then the messages are noticed soon anyway. noatime option NFS-mounted Message Store: Probably OK to use, but safer not to until v1.1 NFS-mounted Control Files: Can be used safely(??) (Or as above??) Local Index Files: Can be used safely(??) Safe. Only maildir tmp/ cleanup checks atimes. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] [Dovecot-news] v1.0.3 released
On Wed, 2007-08-01 at 14:21 +0200, Geert Hendrickx wrote: On Wed, Aug 01, 2007 at 02:41:44PM +0300, Timo Sirainen wrote: 1.0.2 works just fine with it. The version numbers just have happened to be the same earlier. Is this documented somewhere? I guess download page would be the only place where people would actually read that, but it seems a bit wrong place for it. :) Or how do we know which dovecot-sieve version matches which dovecot version(s)? I thought they always had to be the same... No, you can use any Sieve plugin v1.0.x with any Dovecot v1.0.y. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] mbox inbox default
On Wed, 2007-08-01 at 08:58 -0500, [EMAIL PROTECTED] wrote: We're an mbox environment, inboxes in /var/mail/$USER (I'll include dovecot -n output at the bottom of this mail). mail_location is set accordingly for deliver. I'd assumed that if the /var/mail/$USER file doesn't exist, dovecot would create it, but we've discovered from experience (and I verified it in mbox-storage.c) that if access(path, R_OK|W_OK) fails--as it does if the file doesn't exist--that dovecot defaults then to delivering in root_dir/inbox. That access() check is done only if INBOX location isn't explicitly specified. Is this a problem only with deliver or also with imap? mail_location: mbox:~:INBOX=/var/mail/%u:INDEX=/var/mail/.dovecot-index/%1u/%u/ Looks OK. I just tried this: mail_location = mbox:~:INBOX=/var/mail/%u And deliver created the file to /var/mail/ just fine. mail_debug: yes What does Dovecot show in logs when logging in / delivering the message? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] High cpu usage OpenSolaris
Last I heard it was that poll() was called all the time with zero (or 1ms?) timeout. So the problem is probably in src/lib/ioloop.c io_loop_get_wait_time() getting optimized wrong. Hmm.. poll/timeout problems. Sounds suspiciously like: http://groups.google.se/group/comp.unix.solaris/browse_thread/thread/28de6dd19027d8b1/0cb73d002b75ab76?lnk=stq=poll+timeout+1ms+Casper+Dikrnum=2#0cb73d002b75ab76 Just a wild guess, but hey... :-) - Peter
Re: [Dovecot] sieve discard
On Wed, 1 Aug 2007, Geert Hendrickx wrote: On Wed, Aug 01, 2007 at 03:02:38PM +0300, Timo Sirainen wrote: Or I guess since this hasn't been a problem normally I could just remove it unless it becomes a common problem. Updated the text: Use --with-dovecot=path to point to dovecot-config file's directory. There are two possibilities where this could exist: 1) If you configured Dovecot with --enable-header-install, you'll have dovecot-config installed in $prefix/lib/dovecot/ directory. 2) Compiled Dovecot sources' root directory. So for example: ./configure --with-dovecot=/usr/local/lib/dovecot make sudo make install sievec and sieved binaries are built only if you use 2) method, because they need to link with Dovecot's libraries. They can be used to compile and decompile Sieve scripts. You probably don't need these. (1) is very interesting from a packager's point of view (allows me to package dovecot-sieve for pkgsrc much easier), but e.g. pysieved (the python managesieve server) needs sievec for verifying sieve scripts while uploading... I do not know what OS you are packaging for but if you are looking for rpms, fedora has released rpms that include seive in the same srpm as dovecot. I took their .src.rpm and rebuilt it on EL4/Centos4 and it spit out seperate dovecot and sieve binary rpms that so far work as advertised, at least for me. Regards, -- Tom Diehl [EMAIL PROTECTED] Spamtrap address [EMAIL PROTECTED]
Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2
On Wed, 2007-08-01 at 15:27 +0200, Andreas Ntaflos wrote: On Tuesday 31 July 2007 01:41:11 Stephan Bosch wrote: Have fun testing the patch. Notify me when there are problems. Hello Stephan, I still get the following message when trying to connect and authenticate: Choose a different authentication method to PLAIN. The same with LOGIN when I tell Dovecot to use the login authentication method. The logs show: Aug 1 15:25:52 hostname dovecot: managesieve-login: Login: user=username, method=PLAIN, rip=aa.bb.cc.dd, lip=ww.xx.yy.zz, TLS Aug 1 15:25:52 hostname dovecot: MANAGESIEVE(username): Disconnected: Logged out I am using real Unix users and Dovecot is configured with authdb pam and userdb passwd. I previously described the problem in [1]. Does your patch not support PLAIN or LOGIN or am I missing something? Could you give me some more information, i.e. your config, what client you test with and (if possible) a log of the connection. This way I can reproduce the situation. The managesieve patch should support all SASL mechanisms supported by dovecot. In fact, I only test using PLAIN. Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go. Regards, Stephan
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On Aug 1, 2007, at 2:26 AM, Timo Sirainen wrote: On Tue, 2007-07-31 at 17:12 -0700, Jeff Ramsey wrote: I am now getting the following message on all Outlook Clients: Your IMAP Server closed the connectionthis can occur if the connection is idle for too long What does Dovecot show in logs as the disconnect reason? This sounds like the IDLE problem that outlook-idle workaround avoids, but that's the default so I'd think you haven't disabled it. I've got the outlook-idle workaround turned on. I am using this line in the /etc/dovecot.conf: imap_client_workarounds = outlook-idle Dovecot does not show any reason for the disconnect. It just shows that the user logged out: Aug 1 08:09:44 imap dovecot: imap-login: Login: user=jefframsey, method=PLAIN, rip=:::10.11.254.52, lip=:::65.174.242.66 Aug 1 08:09:44 imap dovecot: IMAP(jefframsey): Disconnected: Logged out Aug 1 08:10:06 imap dovecot: imap-login: Login: user=geoff, method=PLAIN, rip=:::10.10.254.148, lip=:::65.174.242.66 Aug 1 08:10:13 imap dovecot: imap-login: Login: user=QUINAULT- donnaanderson, method=PLAIN, rip=:::10.200.254.121, lip=::: 65.174.242.66 Aug 1 08:10:13 imap dovecot: imap-login: Login: user=QUINAULT- donnaanderson, method=PLAIN, rip=:::10.200.254.121, lip=::: 65.174.242.66 Aug 1 08:10:52 imap dovecot: IMAP(QUINAULT-donnaanderson): Disconnected: Logged out Aug 1 08:10:52 imap dovecot: IMAP(QUINAULT-donnaanderson): Disconnected: Logged out I have read that this means that the client was the one that disconnected, but that does not make sense, because with 0.99.x, I did not have this issue. And I did not change anything in my Outlook clients. All I have changed is upgrading Dovecot. Since my initial post, I have noticed this in my log file as well: Aug 1 08:13:42 imap dovecot: auth(default): userdb(johnfowler,::: 65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 Aug 1 08:13:50 imap dovecot: imap-login: Login: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 This does not happen all of the time when a person logs in, in fact I have not heard of a single person having a login failure, or at least nobody has told me they got a message about an improper login or failed password or anything like that so far. The one thing I can think of is maybe the authentication methods have changed for Dovecot from 0.99.x to 1.0.2. I use Winbind to authenticate my Active Directory users to my linux boxen for all of their services, and Dovecot is no exception. Maybe something has changed in the /etc/ pam.d folder. I have not heard of anyone having any authentication errors at this point, however, my own computer, which uses Mac Mail 2.1.1 as a client, has in fact been throwing these errors this morning, a couple of times an hour: The server error encountered was: The user name and password specified in Mail preferences were not accepted by the server. So far, I have not had any error about username and/or password from any of my Outlook users, just this one Mac client. As soon as I click on 'Go Online' at the error screen, the error goes away, and everything is fine for a 5 to 10 minutes, then I'll see it again. And no, it does not happen every time my client syncs folders to IMAP. More like one out of 10 times, and really random. Has anything changed in the way that Dovecot handles authentication that may be causing this issue? The way that (I think) PAM handles authentication from Winbind is first it tries local accounts, and then if they fail, it tries Winbind, so if the local username is not found, it could explain why it is giving this error: Aug 1 08:13:42 imap dovecot: auth(default): userdb(johnfowler,::: 65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 Then, when Winbind auth is tried, the authentication succeeds, and I get: Aug 1 08:13:50 imap dovecot: imap-login: Login: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 So, I can see that the Winbind auth is working, but perhaps Dovecot is sending the client an auth failed after the local auth fails and before the Winbind auth succeeds. Thanks for the suggestions so far, unfortunately I've already tried the outlook-idle workaround. Maybe I should just downgrade to 0.99.x again. Are there any known issues with a downgrade? Jeff Ramsey MIS Administrator TMI Forest Products, Inc. [EMAIL PROTECTED] 360.477.0738 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2
Hi Andreas, On Wed, 2007-08-01 at 16:45 +0200, Stephan Bosch wrote: Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go. I gave it a go and STARTTLS still seems to work fine at my end. This test was performed using 'disable_plaintext_auth = yes' in the config file, forcing a _remote_ host to use TLS/SSL for all protocols. The gnutls-cli tool is very useful to test the STARTTLS command in various protocols. Using the --starttls switch the client starts in plaintext mode and starts the TLS negotiation when Ctrl-D is pressed. With the information you provide I could test it with your setup, but of course you can test it yourself as well. Oh, the end of this transcript might be interesting for Timo. The reported fatal error also occurs on IMAP (dovecot-1.0.2). I don't know whether gnutls-cli is just moaning or whether dovecot is not closing the tls connection very nicely... Regards, Stephan. host:/# gnutls-cli -p 2000 --starttls host.example.com Resolving 'host.example.com'... Connecting to '10.0.0.1:2000'... - Simple Client Mode: IMPLEMENTATION dovecot SASL SIEVE fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric STARTTLS OK Dovecot ready. STARTTLS OK Begin TLS negotiation now. *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'host.example.com'. # valid since: *** # expires at: *** # fingerprint: *** # Subject's DN: O=Dovecot mail server,OU=host.,CN=host.example.com,[EMAIL PROTECTED] # Issuer's DN: O=Dovecot mail server,OU=host.,CN=host.example.com,[EMAIL PROTECTED] - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: DHE RSA - Cipher: AES 256 CBC - MAC: SHA - Compression: DEFLATE IMPLEMENTATION dovecot SASL PLAIN SIEVE fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric OK TLS negotiation successful. AUTHENTICATE PLAIN ** OK Logged in. logout OK Logout completed. *** Fatal error: A TLS packet with unexpected length was received. *** Server has terminated the connection abnormally.
Re: [Dovecot] sieve discard
On Wed, Aug 01, 2007 at 10:52:18AM -0400, Tom Diehl wrote: I do not know what OS you are packaging for but if you are looking for rpms, fedora has released rpms that include seive in the same srpm as dovecot. I took their .src.rpm and rebuilt it on EL4/Centos4 and it spit out seperate dovecot and sieve binary rpms that so far work as advertised, at least for me. This is for pkgsrc (cross-platform, mainly NetBSD and Dragonfly BSD), which (currently) doesn't support creating multiple binary (sub-)packages from a single source package. But I can include the headers in the main dovecot package and have a sieve package depending on that (without sievec/sieved, but that's better than having no sieve package at all). Geert
[Dovecot] OpenBSD and too many open files
I posted some questions a few months back and received lots of great help in getting my dovecot/postfix/LDAP setup working. Initially, I ran into the pipe failed too many open files error. I am running this setup on OpenBSD/sparc64 4.1-stable and so I put dovecot in its own class and upped the maxfiles setting for that class. This was back with dovecot 1.0 and everything worked fine. I just recently upgraded to dovecot 1.0.2 from ports and now I am having the same problems again. I moved kern.maxfiles for that class from 2048 up to 3404 and yet I still run into the error. When I do, I have to restart dovecot to get things running again. Output of: su -c dovecot root -c 'ulimit -a' time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes)8192 lockedmem(kbytes)634482 memory(kbytes) 1898080 nofiles(descriptors) 3404 processes1044 sysctl kern.maxfiles gives: kern.maxfiles=3404 My main IMAP accounts reside on this server and I have somewhere in the 25000 range of stored messages. Could this be causing the issue? I only have maybe a dozen other users using this server right now but I am planning on putting 500 users on it soon. I added another heavy IMAP user shortly before these problems started but I don't know if that has anything to do with it or not. Likewise, I am not sure if the dovecot 1.0.2 upgrade had any effect either although it did coincide. Any ideas? Thank you. Bryan
Re: [Dovecot] OpenBSD and too many open files
On Wed, Aug 01, 2007 at 09:19:11AM -0700, Bryan Vyhmeister wrote: I posted some questions a few months back and received lots of great help in getting my dovecot/postfix/LDAP setup working. Initially, I ran into the pipe failed too many open files error. I am running this setup on OpenBSD/sparc64 4.1-stable and so I put dovecot in its own class and upped the maxfiles setting for that class. This was back with dovecot 1.0 and everything worked fine. I just recently upgraded to dovecot 1.0.2 from ports and now I am having the same problems again. I moved kern.maxfiles for that class from 2048 up to 3404 and yet I still run into the error. When I do, I have to restart dovecot to get things running again. Sounds more like a file descriptor leak. Check fstat output so see what kind of descriptors are leaked, how fast, etc. -- Quentin Garnier - [EMAIL PROTECTED] - [EMAIL PROTECTED] You could have made it, spitting out benchmarks Owe it to yourself not to fail Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005. pgpySJhYug3h9.pgp Description: PGP signature
Re: [Dovecot] OpenBSD and too many open files
On Aug 1, 2007, at 9:25 AM, Quentin Garnier wrote: Sounds more like a file descriptor leak. Check fstat output so see what kind of descriptors are leaked, how fast, etc. Thank you for your quick response. Unfortunately, I restarted dovecot this morning and so this probably isn't very helpful now but here it is anyway. What should I be looking for to indicate a leak? The outputs of 'fstat -u _dovecot' and 'fstat -u _dovecot_login' follow: USER CMD PID FD MOUNTINUM MODE R/WDV|SZ _dovecot imap3328 wd /d1504391 drwx-- r 1024 _dovecot imap33280* internet stream tcp 0x4000d4cba50 66.81.83.13:143 -- 66.81.83.3:52591 _dovecot imap33281* internet stream tcp 0x4000d4cba50 66.81.83.13:143 -- 66.81.83.3:52591 _dovecot imap33282 pipe 0x4000d439c90 state: _dovecot imap33283 / 475071 crw-r--r-- r urandom _dovecot imap33284 kqueue 0x4000d4c7d00 0 state: W _dovecot imap33285 pipe 0x4000d6c7480 state: _dovecot imap33286 pipe 0x4000d6c7480 state: _dovecot imap33289 /d1526304 -rw--- rw 152352 _dovecot imap3328 10 /d1526287 -rw--- rw 9344 _dovecot imap3328 11 /d1514861 -rw--- rw 7173120 _dovecot imap 10524 wd /d1508155 drwx-- r 2048 _dovecot imap 105240* internet stream tcp 0x4000d4cb820 66.81.83.13:143 -- 66.81.83.3:52699 _dovecot imap 105241* internet stream tcp 0x4000d4cb820 66.81.83.13:143 -- 66.81.83.3:52699 _dovecot imap 105242 pipe 0x4000d6c7700 state: _dovecot imap 105243 / 475071 crw-r--r-- r urandom _dovecot imap 105244 kqueue 0x4000d4c7200 0 state: W _dovecot imap 105245 pipe 0x4000d6c7d00 state: _dovecot imap 105246 pipe 0x4000d6c7d00 state: _dovecot imap 32143 wd /d1628354 drwx-- r 512 _dovecot imap 321430* internet stream tcp 0x4000d2f86c0 66.81.83.13:143 -- 66.81.83.3:50414 _dovecot imap 321431* internet stream tcp 0x4000d2f86c0 66.81.83.13:143 -- 66.81.83.3:50414 _dovecot imap 321432 pipe 0x4000d6c7080 state: _dovecot imap 321433 / 475071 crw-r--r-- r urandom _dovecot imap 321434 kqueue 0x4000d4c7a00 0 state: W _dovecot imap 321435 pipe 0x4000d439a90 state: _dovecot imap 321436 pipe 0x4000d439a90 state: _dovecot imap1563 wd /d1794316 drwx-- r 512 _dovecot imap15630* internet stream tcp 0x4000d4ca010 66.81.83.13:143 -- 10.80.1.249:24288 _dovecot imap15631* internet stream tcp 0x4000d4ca010 66.81.83.13:143 -- 10.80.1.249:24288 _dovecot imap15632 pipe 0x4000d6c7a80 state: _dovecot imap15633 / 475071 crw-r--r-- r urandom _dovecot imap15634 kqueue 0x4000d4c6200 0 state: W _dovecot imap15635 pipe 0x4000d6c7c00 state: _dovecot imap15636 pipe 0x4000d6c7c00 state: _dovecot imap9679 wd /d1772316 drwx-- r 512 _dovecot imap96790* internet stream tcp 0x4000d2f93e0 66.81.83.13:143 -- 66.81.83.3:54735 _dovecot imap96791* internet stream tcp 0x4000d2f93e0 66.81.83.13:143 -- 66.81.83.3:54735 _dovecot imap96792 pipe 0x4000d6c6e00 state: _dovecot imap96793 / 475071 crw-r--r-- r urandom _dovecot imap96794 kqueue 0x4000d4c7c00 0 state: W _dovecot imap96795 pipe 0x4000d6c7980 state: _dovecot imap96796 pipe 0x4000d6c7980 state: _dovecot imap 27728 wd /d1772316 drwx-- r 512 _dovecot imap 277280* internet stream tcp 0x4000d2f8030 66.81.83.13:143 -- 66.81.83.3:61851 _dovecot imap 277281* internet stream tcp 0x4000d2f8030 66.81.83.13:143 -- 66.81.83.3:61851 _dovecot imap 277282 pipe 0x4000d6c7c80 state: _dovecot imap 277283 / 475071 crw-r--r-- r urandom _dovecot imap 277284 kqueue 0x4000d4c7300 0 state: W _dovecot imap 277285 pipe 0x4000d6c7680 state: _dovecot imap 277286 pipe 0x4000d6c7680 state: _dovecot imap 277287 /d1772398 -rw--- rw 384 _dovecot imap 277288 /d1772332 -rw--- rw 3480 _dovecot imap 277289 /d1772337 -rw--- rw21504 _dovecot imap 23686 wd /d1525067 drwx-- r 512 _dovecot imap 236860* internet stream tcp 0x4000d4cbc80 66.81.83.13:143 -- 66.81.83.3:56740 _dovecot imap 236861* internet stream tcp 0x4000d4cbc80 66.81.83.13:143 -- 66.81.83.3:56740 _dovecot imap 236862 pipe 0x4000d439d90 state: _dovecot imap 236863 / 475071 crw-r--r-- r urandom _dovecot imap 236864 kqueue 0x4000d4c7b00 0 state: W _dovecot imap
Re: [Dovecot] OpenBSD and too many open files
On 1.8.2007, at 19.43, Quentin Garnier wrote: FWIW, I've stopped using dovecot's kqueue code quite some time ago because it would leak one fd almost every login, leading to the kind of situation you experience. I wish I had the time to debug that, but unfortunately... I thought this happened only with older NetBSDs. I tested it myself once with 3.0 (or 3.1?) and I couldn't get it to leak. But yes, with some NetBSD versions it does leak one pipe per each died process because kqueue doesn't notice that the pipe was closed by the other side and give an event, or something like that. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2
On Wednesday 01 August 2007 17:53:16 Stephan Bosch wrote: Hi Andreas, On Wed, 2007-08-01 at 16:45 +0200, Stephan Bosch wrote: Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go. I gave it a go and STARTTLS still seems to work fine at my end. This test was performed using 'disable_plaintext_auth = yes' in the config file, forcing a _remote_ host to use TLS/SSL for all protocols. Thanks for taking the time to investigate this further! I will try to provide you with everything I can. I have my server configured the same way, allowing only TLS connections for plaintext login on the standard IMAP port 143. I shall attach the output of dovecot -n. The gnutls-cli tool is very useful to test the STARTTLS command in various protocols. Using the --starttls switch the client starts in plaintext mode and starts the TLS negotiation when Ctrl-D is pressed. With the information you provide I could test it with your setup, but of course you can test it yourself as well. I got this working just fine, using the method you described below. Of course I had to base64-encode the username\0username\0password string first, which is probably not so obvious to someone who doesn't have much experience debugging authentication problems :) I am using KMail 1.9.7 and KDE 3.5.7 to connect to the server (KDE has a kioslave for sieve). But seeing that connecting and authenticating worked fine with gnutls-cli this seems to be a KMail- oder KDE-related problem? Is there anything else I can provide? How do you want the connection log? As the output of a tcpdump session? Thanks again! Andreas # 1.0.2: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap managesieve listen(default): * listen(imap): * listen(managesieve): *:2000 ssl_cert_file: /etc/ssl/certs/pseudoterminal.org_dovecot.crt ssl_key_file: /etc/ssl/private/pseudoterminal.org.key login_dir(default): /var/run/dovecot//login login_dir(imap): /var/run/dovecot//login login_dir(managesieve): login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login mail_extra_groups: mail mail_location: maildir:~/Maildir maildir_copy_with_hardlinks: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(managesieve): outlook-idle namespace: type: public separator: / prefix: Public/ location: maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public namespace: type: private separator: / inbox: yes auth default: mechanisms: plain login passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix -- Andreas daff Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] OpenBSD and too many open files
On 1.8.2007, at 19.36, Bryan Vyhmeister wrote: On Aug 1, 2007, at 9:25 AM, Quentin Garnier wrote: Sounds more like a file descriptor leak. Check fstat output so see what kind of descriptors are leaked, how fast, etc. Thank you for your quick response. Unfortunately, I restarted dovecot this morning and so this probably isn't very helpful now but here it is anyway. What should I be looking for to indicate a leak? The outputs of 'fstat -u _dovecot' and 'fstat -u _dovecot_login' follow: You didn't say which process got the too many files error, but usually it's the Dovecot master process. Could you show the exact error message so I can be sure? Here you showed only imap, imap-login and pop3-login processes, not dovecot process. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] OpenBSD and too many open files
On Wed, Aug 01, 2007 at 07:52:33PM +0300, Timo Sirainen wrote: On 1.8.2007, at 19.43, Quentin Garnier wrote: FWIW, I've stopped using dovecot's kqueue code quite some time ago because it would leak one fd almost every login, leading to the kind of situation you experience. I wish I had the time to debug that, but unfortunately... I thought this happened only with older NetBSDs. I tested it myself once with 3.0 (or 3.1?) and I couldn't get it to leak. Yes, older NetBSDs. What do you think OpenBSD is? Nah, just kidding. I don't remember what tests I did at the time. I do remember that I couldn't reproduce it as easily as I wanted to, and the likely cause was that I was doing my tests on a kernel more recent than the 2.0 of my prod servers. But yes, with some NetBSD versions it does leak one pipe per each died process because kqueue doesn't notice that the pipe was closed by the other side and give an event, or something like that. Which does look like what is experienced here. Now, I don't know if we can locate easily what fix needs to be applied to OpenBSD. -- Quentin Garnier - [EMAIL PROTECTED] - [EMAIL PROTECTED] You could have made it, spitting out benchmarks Owe it to yourself not to fail Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005. pgpD0xU0rL5Rv.pgp Description: PGP signature
Re: [Dovecot] OpenBSD and too many open files
On Wed, Aug 01, 2007 at 09:36:49AM -0700, Bryan Vyhmeister wrote: On Aug 1, 2007, at 9:25 AM, Quentin Garnier wrote: Sounds more like a file descriptor leak. Check fstat output so see what kind of descriptors are leaked, how fast, etc. Thank you for your quick response. Unfortunately, I restarted dovecot this morning and so this probably isn't very helpful now but here it is anyway. What should I be looking for to indicate a leak? The outputs of 'fstat -u _dovecot' and 'fstat -u _dovecot_login' follow: Oh, you're using kqueue. I didn't know OpenBSD eventually grew support for it. FWIW, I've stopped using dovecot's kqueue code quite some time ago because it would leak one fd almost every login, leading to the kind of situation you experience. I wish I had the time to debug that, but unfortunately... -- Quentin Garnier - [EMAIL PROTECTED] - [EMAIL PROTECTED] You could have made it, spitting out benchmarks Owe it to yourself not to fail Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005. pgpGVLfv1CHtg.pgp Description: PGP signature
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On 1.8.2007, at 18.43, Jeff Ramsey wrote: Aug 1 08:09:44 imap dovecot: imap-login: Login: user=jefframsey, method=PLAIN, rip=:::10.11.254.52, lip=:::65.174.242.66 Aug 1 08:09:44 imap dovecot: IMAP(jefframsey): Disconnected: Logged out I have read that this means that the client was the one that disconnected, but that does not make sense, because with 0.99.x, I did not have this issue. And I did not change anything in my Outlook clients. All I have changed is upgrading Dovecot. Logged out means that client sent a LOGOUT command. Since my initial post, I have noticed this in my log file as well: Aug 1 08:13:42 imap dovecot: auth(default): userdb (johnfowler,:::65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 I suppose this is the problem then. Outlook stupidly keeps reconnecting to server all the time, so if one reconnection fails I guess this problem happens. So this johnfowler really should exist in your userdb? You could set auth_debug=yes and then see what is logged before that error. Also could you post your dovecot -n output? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] OpenBSD and too many open files
On Aug 1, 2007, at 9:41 AM, Timo Sirainen wrote: You didn't say which process got the too many files error, but usually it's the Dovecot master process. Could you show the exact error message so I can be sure? Here you showed only imap, imap- login and pop3-login processes, not dovecot process. You're right. Sorry, I couldn't find the error message initially but I just located it. It appears like this particular error appears in the context of a dictionary attack. Jul 30 07:31:02 a dovecot: pop3-login: Aborted login: user=aaron, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:02 a dovecot: pop3-login: Aborted login: user=support, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:02 a dovecot: pop3-login: Aborted login: user=support, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:02 a dovecot: pop3-login: Aborted login: user=aaron, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:02 a dovecot: pop3-login: Aborted login: user=aaron, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:03 a dovecot: pipe() failed: Too many open files Jul 30 07:31:03 a dovecot: Temporary failure in creating login processes, slowing down for now Jul 30 07:31:03 a dovecot: Created login processes successfully, unstalling Jul 30 07:31:04 a dovecot: pop3-login: Aborted login: user=spam, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:04 a dovecot: pop3-login: Aborted login: user=abigail, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 30 07:31:04 a dovecot: pop3-login: Aborted login: user=abraham, method=PLAIN, rip=69.3.64.3, lip=66.81.83.13 Jul 28 21:13:01 a dovecot: pipe() failed: Too many open files Jul 28 21:13:55 a postfix/smtpd[14992]: connect from exprod6mx146.postini.com[64.18.1.118] Jul 28 21:13:55 a postfix/smtpd[14992]: F0A36142011: client=exprod6mx146.postini.com[64.18.1.118] Jul 28 21:13:56 a postfix/smtpd[14992]: disconnect from exprod6mx146.postini.com[64.18.1.118] Jul 28 21:14:01 a dovecot: pipe() failed: Too many open files Jul 28 21:15:01 a dovecot: pipe() failed: Too many open files Jul 28 21:15:10 a postfix/smtpd[14992]: connect from exprod6mx183.postini.com[64.18.1.74] Jul 28 21:15:10 a postfix/smtpd[14992]: D28A8142011: client=exprod6mx183.postini.com[64.18.1.74] Jul 28 21:15:10 a postfix/smtpd[14992]: disconnect from exprod6mx183.postini.com[64.18.1.74] Also, here is fstat output for the master process: USER CMD PID FD MOUNTINUM MODE R/WDV|SZ root dovecot 5846 wd / 1319569 drwxr-xr-x r 512 root dovecot 58460 / 475354 crw-rw-rw- r null root dovecot 58461 / 475354 crw-rw-rw- r null root dovecot 58462 / 475354 crw-rw-rw- r null root dovecot 58463 / 475354 crw-rw-rw- r null root dovecot 58464 / 475354 crw-rw-rw- r null root dovecot 58465* internet stream tcp 0x4000d50fa40 *:143 root dovecot 58466* internet stream tcp 0x4000d4ca240 *:993 root dovecot 58467* internet stream tcp 0x4000d2f8b20 *:110 root dovecot 58468* internet stream tcp 0x4000d2f88f0 *:995 root dovecot 58469 kqueue 0x4000d4c7600 0 state: W root dovecot 5846 10* unix dgram 0x4000252c400 - 0x400022ac580 root dovecot 5846 11 pipe 0x4000d438f10 state: root dovecot 5846 12 pipe 0x4000d438f10 state: root dovecot 5846 13* unix stream 0x4000252bf80 root dovecot 5846 14* unix stream 0x4000238a500 root dovecot 5846 15* unix stream 0x4000251c680 - 0x4000250d000 root dovecot 5846 16* unix stream 0x40002404200 - 0x40002517200 root dovecot 5846 17 pipe 0x4000d439310 state: root dovecot 5846 18* unix stream 0x40002484c00 - 0x40002520600 root dovecot 5846 19* unix stream 0x400023ab280 root dovecot 5846 20* unix stream 0x40002501a00 - 0x40002501000 root dovecot 5846 21* unix stream 0x40002372800 - 0x4000251be80 root dovecot 5846 22 pipe 0x4000d439b90 state: root dovecot 5846 23* unix stream 0x40002484880 - 0x4000252c900 root dovecot 5846 24 pipe 0x4000d439490 state: root dovecot 5846 25* unix stream 0x400024f6000 - 0x40002514500 root dovecot 5846 26 pipe 0x4000d439d10 state: root dovecot 5846 27* unix stream 0x4000250bb00 - 0x400024f6280 root dovecot 5846 28 pipe 0x4000d438c10 state: root dovecot 5846 30 pipe 0x4000d439a90 state: root dovecot 5846 31 pipe 0x4000d439c10 state: root dovecot 5846 32 pipe 0x4000d439790 state: root dovecot 5846 33 pipe 0x4000d6c7700 state: root dovecot 5846 34 pipe 0x4000d439610 state: root dovecot 5846 35* unix stream 0x4000251ef00 - 0x4000250ba80 root dovecot 5846 37* unix stream 0x40002516300 -
Re: [Dovecot] OpenBSD and too many open files
On Aug 1, 2007, at 9:52 AM, Timo Sirainen wrote: On 1.8.2007, at 19.43, Quentin Garnier wrote: FWIW, I've stopped using dovecot's kqueue code quite some time ago because it would leak one fd almost every login, leading to the kind of situation you experience. I wish I had the time to debug that, but unfortunately... I thought this happened only with older NetBSDs. I tested it myself once with 3.0 (or 3.1?) and I couldn't get it to leak. But yes, with some NetBSD versions it does leak one pipe per each died process because kqueue doesn't notice that the pipe was closed by the other side and give an event, or something like that. I am guessing that OpenBSD is affected in the same way? Bryan
Re: [Dovecot] OpenBSD and too many open files
On Wed, Aug 01, 2007 at 07:01:35PM +0200, Quentin Garnier wrote: [...] Which does look like what is experienced here. Now, I don't know if we can locate easily what fix needs to be applied to OpenBSD. Check if this applies to OpenBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_pipe.c.diff?r1=1.65r2=1.66f=h -- Quentin Garnier - [EMAIL PROTECTED] - [EMAIL PROTECTED] You could have made it, spitting out benchmarks Owe it to yourself not to fail Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005. pgp3a48w6oG4Z.pgp Description: PGP signature
Re: [Dovecot] OpenBSD and too many open files
On Aug 1, 2007, at 10:37 AM, Quentin Garnier wrote: On Wed, Aug 01, 2007 at 07:01:35PM +0200, Quentin Garnier wrote: [...] Which does look like what is experienced here. Now, I don't know if we can locate easily what fix needs to be applied to OpenBSD. Check if this applies to OpenBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_pipe.c.diff? r1=1.65r2=1.66f=h From looking at: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/kern/ sys_pipe.c?rev=1.51content-type=text/plain I can't quite tell. There are significant differences. I'll have to take a closer look after a work engagement. Bryan
Re: [Dovecot] OpenBSD and too many open files
On Wed, Aug 01, 2007 at 10:56:26AM -0700, Bryan Vyhmeister wrote:
On Aug 1, 2007, at 10:37 AM, Quentin Garnier wrote:
On Wed, Aug 01, 2007 at 07:01:35PM +0200, Quentin Garnier wrote:
[...]
Which does look like what is experienced here. Now, I don't know
if we
can locate easily what fix needs to be applied to OpenBSD.
Check if this applies to OpenBSD:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_pipe.c.diff?
r1=1.65r2=1.66f=h
From looking at:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/kern/
sys_pipe.c?rev=1.51content-type=text/plain
I can't quite tell. There are significant differences. I'll have to
take a closer look after a work engagement.
Well, the problem is Christos did some other stuff in that commit than
just fixing the bug. Try the attached patch.
--
Quentin Garnier - [EMAIL PROTECTED] - [EMAIL PROTECTED]
You could have made it, spitting out benchmarks
Owe it to yourself not to fail
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
--- sys_pipe.c.orig 2006-11-17 10:21:52.0 +0100
+++ sys_pipe.c 2007-08-01 20:08:09.0 +0200
@@ -735,9 +735,10 @@
* If the other side is blocked, wake it up saying that
* we want to close it down.
*/
+ cpipe-pipe_state |= PIPE_EOF;
while (cpipe-pipe_busy) {
wakeup(cpipe);
- cpipe-pipe_state |= PIPE_WANT | PIPE_EOF;
+ cpipe-pipe_state |= PIPE_WANT;
tsleep(cpipe, PRIBIO, pipecl, 0);
}
pgp8Mu7Mk2xS3.pgp
Description: PGP signature
[Dovecot] How do I configure sendmail to accept emails for dovecot when dovecot has sql auth/user db.
Included below are my config files: sendmail.mc, dovecot.m4,
dovecot.conf, dovecot-sql.conf. Whenever I try to send email into
this system, it rejects it with user does not exist, however, the
user does exist as far as dovecot (imap) is concerned, it is in the
database.
THANKS - Yossie
# for i in /etc/dovecot/dovecot.conf /etc/dovecot/dovecot-sql.conf /
usr/share/sendmail-cf/mailer/dovecot.m4 /etc/mail/sendmail.mc; do
echo FILE: $i; echo ===; echo ; egrep -v '^ *(#|$)' $i; echo ;
echo ; done
FILE: /etc/dovecot/dovecot.conf
===
listen = [::]
disable_plaintext_auth = no
ssl_disable = yes
ssl_cert_file = /etc/ssl/dovecot/server.pem
ssl_key_file = /etc/ssl/dovecot/server.key
mail_location = maildir:~/.maildir
namespace private {
separator = .
inbox = yes
hidden = no
}
namespace private {
separator = .
prefix = INBOX.
inbox = no
hidden = yes
}
first_valid_uid = 0
protocol imap {
}
protocol pop3 {
}
protocol lda {
postmaster_address = [EMAIL PROTECTED]
main_plugin_dir = /usr/lib/dovecot/lda
mail_plugins = cmusieve quota
}
auth default {
mechanisms = plain
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
user = root
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0666
}
client {
path = /var/run/dovecot/auth-client
mode = 0666
}
}
}
dict {
}
plugin {
}
FILE: /etc/dovecot/dovecot-sql.conf
===
driver = mysql
connect = host=localhost dbname=dovecot user=root
default_pass_scheme = PLAIN
password_query = SELECT userPassword as password, user, concat(/var/
spool/dovecot/,substr(user,1,1),/user/,user) as userdb_home, 97 as
userdb_uid, 97 as userdb_gid FROM authdb WHERE user = '%n' and
userPassword = '%w'
user_query = SELECT concat(/var/spool/imap/,substr(user,1,1),/
user/,user) as home, 97 as uid, 97 as gid FROM authdb WHERE user = '%n'
FILE: /usr/share/sendmail-cf/mailer/dovecot.m4
===
Mdovecot, P=/usr/libexec/dovecot/deliver, F=DFMPhnu9,
S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,
T=DNS/RFC822/X-Unix,
A=deliver -d $u
FILE: /etc/mail/sendmail.mc
===
divert(-1)
dnl This is the macro config file used to generate the /etc/sendmail.cf
dnl file. If you modify the file you will have to regenerate the
dnl /etc/sendmail.cf by running this macro config through the m4
dnl preprocessor:
dnl
dnlm4 /etc/mail/sendmail.mc /etc/mail/sendmail.cf
dnl
dnl You will need to have the sendmail-cf package installed for this to
dnl work.
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
define(`confDEF_USER_ID',``mail:mail'')dnl
OSTYPE(`linux')dnl
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dnl
define(`confALIAS_WAIT', `30')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
dnl define delivery mode: interactive, background, or queued
dnl define(`confDELIVERY_MODE', `i')
MASQUERADE_AS(`ford.qa.laszlosystems.com')dnl
FEATURE(`limited_masquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(mailertable)dnl
dnl virtusertable: redirect incoming mail to virtual domain to
particular user or domain
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
dnl genericstable: rewrite sender address for outgoing mail
FEATURE(genericstable)dnl
FEATURE(always_add_domain)dnl
FEATURE(redirect)dnl
FEATURE(use_cw_file)dnl
FEATURE(local_procmail)dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`relay_based_on_MX')dnl
dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see
http://www.mail-abuse.org/rbl/')dnl
dnl FEATURE(dnsbl, `dialups.mail-abuse.org', `Dialup - see http://
www.mail-abuse.org/dul/')dnl
dnl FEATURE(dnsbl, `relays.mail-abuse.org', `Open spam relay - see
http://www.mail-abuse.org/rss/')dnl
FEATURE(`delay_checks')dnl
FEATURE(`stickyhost')dnl
dnl SASL Configuration
dnl extract from http://www.sendmail.org/~ca/email/auth.html
dnl
dnl Next two lines are for SMTP Authentication
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
dnl
dnl Next line stops sendmail from allowing auth without encryption
define(`confAUTH_OPTIONS', `Apy')dnl
dnl
dnl STARTTLS configuration
dnl extract from http://www.sendmail.org/~ca/email/starttls.html
dnl
define(`CERT_DIR', `/etc/ssl/sendmail')dnl
define(`confCACERT_PATH', `CERT_DIR')dnl
define(`confCACERT', `CERT_DIR/CAcert.pem')dnl
define(`confSERVER_CERT', `CERT_DIR/MYcert.pem')dnl
define(`confSERVER_KEY', `CERT_DIR/MYkey.pem')dnl
define(`confCLIENT_CERT', `CERT_DIR/MYcert.pem')dnl
define(`confCLIENT_KEY', `CERT_DIR/MYkey.pem')dnl
dnl
dnl Uncomment next lines to hide identity of mail serve
define(`confPRIVACY_FLAGS',`goaway,restrictqrun,restrictmailq')dnl
dnl define(`confSMTP_LOGIN_MSG', `$j server ready at $b')dnl
Re: [Dovecot] mbox inbox default
On Aug 1 2007, Timo Sirainen wrote: On Wed, 2007-08-01 at 08:58 -0500, [EMAIL PROTECTED] wrote: We're an mbox environment, inboxes in /var/mail/$USER (I'll include dovecot -n output at the bottom of this mail). mail_location is set accordingly for deliver. I'd assumed that if the /var/mail/$USER file doesn't exist, dovecot would create it, but we've discovered from experience (and I verified it in mbox-storage.c) that if access(path, R_OK|W_OK) fails--as it does if the file doesn't exist--that dovecot defaults then to delivering in root_dir/inbox. That access() check is done only if INBOX location isn't explicitly specified. Is this a problem only with deliver or also with imap? Deliver only. On further review, I discovered where the problem lies locally, it was not a Dovecot issue. Sorry to bother. :) Thanks for your help, -Brian
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On Aug 1, 2007, at 9:47 AM, Timo Sirainen wrote: On 1.8.2007, at 18.43, Jeff Ramsey wrote: Since my initial post, I have noticed this in my log file as well: Aug 1 08:13:42 imap dovecot: auth(default): userdb (johnfowler,:::65.174.242.248): user not found from userdb Aug 1 08:13:42 imap dovecot: imap-login: Internal login failure: user=johnfowler, method=PLAIN, rip=:::65.174.242.248, lip=:::65.174.242.66 I suppose this is the problem then. Outlook stupidly keeps reconnecting to server all the time, so if one reconnection fails I guess this problem happens. So this johnfowler really should exist in your userdb? You could set auth_debug=yes and then see what is logged before that error. Also could you post your dovecot -n output? Output of dovecot -n: # 1.0.2: /etc/dovecot.conf login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: passdb: driver: pam userdb: driver: passwd And yes, issuing a 'getent passwd' command shows all of my users from the /etc/passwd file, and then all of the Active Directory users, including johnfowler. I set auth_debug = yes. Here is an example to compare to the previous one with johnfowler, this one with QUINAULT-ileneyoung as the username; (QUINAULT is a trusted Active Directory domain, so I have to prefix the username with the DOMAIN for this user.) Aug 1 11:58:47 imap dovecot: auth(default): pam(QUINAULT- ileneyoung,:::10.200.254.110): lookup service=dovecot Aug 1 11:58:47 imap dovecot: auth(default): client out: OK 1 user=QUINAULT-ileneyoung Aug 1 11:58:47 imap dovecot: auth(default): master in: REQUEST 3 12173 1 Aug 1 11:58:47 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,:::10.200.254.110): lookup Aug 1 11:58:47 imap dovecot: auth(default): master out: USER 3 QUINAULT-ileneyoung system_user=QUINAULT-ileneyoung uid=16777352gid=16777248home=/home/QUINAULT/ileneyoung Aug 1 11:58:47 imap dovecot: imap-login: Login: user=QUINAULT- ileneyoung, method=PLAIN, rip=:::10.200.254.110, lip=::: 65.174.242.66 Aug 1 11:58:51 imap dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAPlip=:::65.174.242.66 rip=:::10.200.254.110 resp=hidden Aug 1 11:58:51 imap dovecot: auth(default): pam(QUINAULT- ileneyoung,:::10.200.254.110): lookup service=dovecot Aug 1 11:58:51 imap dovecot: auth(default): client out: OK 1 user=QUINAULT-ileneyoung Aug 1 11:58:51 imap dovecot: auth(default): master in: REQUEST 4 12186 1 Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,:::10.200.254.110): lookup Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,:::10.200.254.110): unknown user Aug 1 11:58:51 imap dovecot: auth(default): userdb(QUINAULT- ileneyoung,:::10.200.254.110): user not found from userdb Aug 1 11:58:51 imap dovecot: auth(default): master out: NOTFOUND 4 Aug 1 11:58:51 imap dovecot: imap-login: Internal login failure: user=QUINAULT-ileneyoung, method=PLAIN, rip=:::10.200.254.110, lip=:::65.174.242.66 Aug 1 11:59:06 imap dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAPlip=:::65.174.242.66 rip=:::65.174.242.239 resp=hidden Perhaps this sheds some light on the matter? Why is it trying to authenticate the user again at 11:58:51 when there was no disconnect after 11:58:47? And why is it failing? My guess on why it is failing is because the Active Directory Server cannot respond fast enough to handle the second request, after already handling the first, but I am just guessing. Thanks, Jeff Ramsey MIS Administrator TMI Forest Products, Inc. [EMAIL PROTECTED] 360.477.0738 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] dovecot-auth core dumps
Sorry about the no 'bt full'. Program received signal SIGSEGV, Segmentation fault. 0x107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 (gdb) bt full #0 0x107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x004140cb in mech_deinit () No symbol table info available. #2 0x0040f38f in auth_request_handler_flush_failures () No symbol table info available. #3 0x00421df9 in io_loop_handle_timeouts () No symbol table info available. #4 0x0042287a in io_loop_handler_run () No symbol table info available. #5 0x00421eca in io_loop_run () No symbol table info available. #6 0x00411dfb in main () No symbol table info available. I use the 'masteruser' config on my proxies to let me accept secure passwords before I proxy off the connection to the storage servers. I suppose I could disable gssapi on the proxies, but figured I'd send this your way just in case there was a looming issue. I believe gssapi did work in the past, but can't quite remember. -c On 8/1/07, Timo Sirainen [EMAIL PROTECTED] wrote: On Wed, 2007-08-01 at 13:01 -0600, Cassidy B. Larson wrote: It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want: .. Program received signal SIGSEGV, Segmentation fault. 0x107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 I would have still wanted bt full, but .. So you really have allowed GSSAPI authentication for your proxy? Does it work normally? If not, how about just disabling it? :) I've no idea if it's supposed to even work..
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On Wed, 2007-08-01 at 12:05 -0700, Jeff Ramsey wrote: Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,:::10.200.254.110): lookup Aug 1 11:58:51 imap dovecot: auth(default): passwd(QUINAULT- ileneyoung,:::10.200.254.110): unknown user .. Perhaps this sheds some light on the matter? Why is it trying to authenticate the user again at 11:58:51 when there was no disconnect after 11:58:47? Outlook just wanted to create yet another connection. And why is it failing? My guess on why it is failing is because the Active Directory Server cannot respond fast enough to handle the second request, after already handling the first, but I am just guessing. I think the problem has to do with NSS. It probably failed with some error, but since unfortunately getpwnam() interface doesn't support reporting errors, Dovecot just assumed that the user didn't exist. I can't think of why this would work any differently with Dovecot v0.99.x. I think you should rather get rid of userdb passwd and configure Dovecot to use userdb ldap to connect directly to your AD. Using / not using nscd might also help. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot-auth core dumps
It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want: [EMAIL PROTECTED] ~]# gdb /usr/local/libexec/dovecot/dovecot-auth 5863 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Attaching to program: /usr/local/libexec/dovecot/dovecot-auth, process 5863 Reading symbols from /usr/lib/libpam.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpam.so.3 Reading symbols from /usr/lib/libgssapi.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi.so.8 Reading symbols from /usr/lib/libkrb5.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.8 Reading symbols from /usr/lib/libasn1.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libroken.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libroken.so.8 Reading symbols from /usr/lib/libcom_err.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcom_err.so.3 Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.15 Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 0x1149031c in kevent () from /lib/libc.so.6 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 --- On 8/1/07, Timo Sirainen [EMAIL PROTECTED] wrote: On Mon, 2007-07-30 at 14:06 -0600, Cassidy B. Larson wrote: gdb /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot- auth.core This looks correct. (gdb) bt full #0 0x180abc22 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x08059246 in mech_deinit () No symbol table info available. #2 0x08053f12 in auth_request_handler_unref () No symbol table info available. #3 0x08050bef in auth_client_connection_destroy () No symbol table info available. #4 0x08050ead in auth_client_connection_create () No symbol table info available. #5 0x08065f54 in io_loop_handler_run () No symbol table info available. #6 0x08065605 in io_loop_run () No symbol table info available. #7 0x0805722a in main () No symbol table info available. But this looks broken unfortunately. Usually it happens if the core file wasn't created by the exact same binary you gave to gdb. One way to be sure would be to attach gdb to dovecot-auth while it's still running: gdb /usr/local/libexec/dovecot/dovecot-auth pid of dovecot-auth continue wait for crash bt full Also your dovecot-auth doesn't contain debugging information. It would be helpful to have that (make install probably strips them), but maybe not required if I just can get a nonbroken backtrace.
Re: [Dovecot] dovecot-auth core dumps
On Wed, 2007-08-01 at 13:01 -0600, Cassidy B. Larson wrote: It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want: .. Program received signal SIGSEGV, Segmentation fault. 0x107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 I would have still wanted bt full, but .. So you really have allowed GSSAPI authentication for your proxy? Does it work normally? If not, how about just disabling it? :) I've no idea if it's supposed to even work.. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Outlook 2000/2003 frequent disconnect issue
On Aug 1, 2007, at 12:10 PM, Timo Sirainen wrote: I think the problem has to do with NSS. It probably failed with some error, but since unfortunately getpwnam() interface doesn't support reporting errors, Dovecot just assumed that the user didn't exist. I can't think of why this would work any differently with Dovecot v0.99.x. I think you should rather get rid of userdb passwd and configure Dovecot to use userdb ldap to connect directly to your AD. Using / not using nscd might also help. I think going to userdb ldap may be a great long term solution, however I'll need to setup an offline computer to configure and test it on before I could run it live. Is there any way that I can just downgrade back to 0.99.x to see if this issue is in fact caused by a difference between the two versions? Will downgrading cause any known issues? If I could just get this working like it was before the upgrade to 1.0.2-2, I'd have enough time to setup and test userdb ldap. Jeff Ramsey MIS Administrator TMI Forest Products, Inc. [EMAIL PROTECTED] 360.477.0738 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] sieve discard
On Wed, Aug 01, 2007 at 03:02:38PM +0300, Timo Sirainen wrote: sievec and sieved binaries are built only if you use 2) method, because they need to link with Dovecot's libraries. They can be used to compile and decompile Sieve scripts. You probably don't need these. According to the Makefile, they only need liblib.a to build. Can't this file be installed as well with --enable-header-install (you may want to rename this flag then), so that dovecot-sieve can fully be built against an installed dovecot package? Geert
Re: [Dovecot] dovecot: child 1690 (auth-worker) killed with signal 11
* Thomas Zajic, 2007-08-01 21:37 #1 0x08056954 in auth_worker_handle_passl (client=0x8089e18, id=3, args=0x808a082 user=zlatko-mail\tservice=IMAP\tlip=192.168.1.3\trip=192.168.1.1\tsecured=1) at auth-worker-client.c:242 auth_request = (struct auth_request *) 0x808a3f0 credentials_str = 0x2 Address 0x2 out of bounds Sorry, forgot to mention that in the original report: I don't know if that's important, but the problematic credentials_str *always* has the same value (0x2), in each and every core dump. HTH, Thomas -- =-= - Thomas ZlatkO Zajic [EMAIL PROTECTED] Linux-2.6.21 Thunderbird-2.0 - - It is not easy to cut through a human head with a hacksaw. (M. C.) - =-=
[Dovecot] dovecot: child 1690 (auth-worker) killed with signal 11
Hi there,
I've been seeing this for quite a while now, but only today finally got
off my lazy you-know-what and did a backtrace. Here's the requested info
as per http://dovecot.org/bugreport.html:
* Dovecot version
[EMAIL PROTECTED]:~# dovecot --version
1.0.3
* Operating system or Linux distribution name
Slackware 10.2, both kernel 2.6.21.3 and dovecot self-compiled
* CPU architecture (x86 or something else?)
x86 (AMD Athlon XP 3200+)
* Filesystem you used (especially if you use NFS or not)
ext3, local (no NFS)
* Some kind of description of what you were doing and with what IMAP client.
Thunderbird 2.0.0.4 (also happened with earlier versions)
mail-notification-4.1 ( )
* If the problem can be reproduced, it helps a lot if you can tell how.
Happens in almost regular intervals, not sure when exactly though. Usually
when doing something in TB again (deleting or moving mails) after it has
been sitting idling for a while. From the log files going back to July 22nd:
[EMAIL PROTECTED]:~# grep dovecot: child .* (auth-worker) killed with signal
11 /var/log/maillog* | wc -l
258
TB is configured to use TLS and secure authentication, use IDLE, and 5
cached server connections. Mail Notification is configured to use TLS,
and to autodetect both the authentication mechanism and IDLE availability.
* Dovecot configuration with dovecot -n
[EMAIL PROTECTED]:~# dovecot -n
# 1.0.3: /usr/local/etc/dovecot.conf
login_dir: /usr/local/var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
login_greeting_capability: yes
verbose_proctitle: yes
mail_location: maildir:/home/%u/Maildir:INBOX=/home/%u/Maildir/.INBOX
mail_debug: yes
fsync_disable: yes
maildir_copy_with_hardlinks: yes
mail_drop_priv_before_exec: yes
auth default:
mechanisms: plain digest-md5 cram-md5
debug: yes
passdb:
driver: shadow
args: blocking=yes
passdb:
driver: passwd-file
args: /usr/local/etc/dovecot-passwd
userdb:
driver: passwd
args: blocking=yes
* Backtrace
[EMAIL PROTECTED]:~# gdb /usr/local/libexec/dovecot/dovecot-auth
/usr/local/stow/dovecot-data/var/run/dovecot/core
GNU gdb 6.3
[...]
Core was generated by `dovecot-auth -w'.
Program terminated with signal 11, Segmentation fault.
[...]
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x08056954 in auth_worker_handle_passl (client=0x8089e18, id=3,
args=0x808a082
user=zlatko-mail\tservice=IMAP\tlip=192.168.1.3\trip=192.168.1.1\tsecured=1)
at auth-worker-client.c:242
auth_request = (struct auth_request *) 0x808a3f0
credentials_str = 0x2 Address 0x2 out of bounds
#2 0x08056c15 in auth_worker_handle_line (client=0x8089e18,
line=0x808a078
PASSL\t1\t2\tuser=zlatko-mail\tservice=IMAP\tlip=192.168.1.3\trip=192.168.1.1\tsecured=1)
at auth-worker-client.c:326
id = 3
#3 0x08056ca7 in auth_worker_input (context=0x8085ac8) at
auth-worker-client.c:359
client = (struct auth_worker_client *) 0x8089e18
line = 0x808a076
3\tPASSL\t1\t2\tuser=zlatko-mail\tservice=IMAP\tlip=192.168.1.3\trip=192.168.1.1\tsecured=1
ret = 118
#4 0x0806b841 in io_loop_handler_run (ioloop=0x80851a8) at ioloop-poll.c:199
ctx = (struct ioloop_handler_context *) 0x80851d0
pollfd = (struct pollfd *) 0x80851f0
tv = {tv_sec = 1, tv_usec = 999620}
io = (struct io *) 0x8089f88
t_id = 2
msecs = 134765256
ret = 0
call = true
#5 0x0806ae89 in io_loop_run (ioloop=0x80851a8) at ioloop.c:329
No locals.
#6 0x0805a04b in main (argc=2, argv=0xbfa36e98) at main.c:321
foreground = false
(gdb)
Please let me know if you need any additional info (log snippets, etc.).
Thanks,
Thomas
--
=-=
- Thomas ZlatkO Zajic [EMAIL PROTECTED] Linux-2.6.21 Thunderbird-2.0 -
- It is not easy to cut through a human head with a hacksaw. (M. C.) -
=-=
[Dovecot] Editing sieve files
Hi all I've got a standard dovecot setup: home is /var/spool/vmail/domain/user/ uid: vmail gid: vmail Sieve file is: /var/spool/vmail/domain/user/.dovecot.sieve if i want to change the dovecot-sieve file to modify the rules (or even let my users do it at some point) then it has to been done by root. Is there a way to setup the sieve plugin so a user can create his own rules? sort of like ~/.procmailrc TIA jalal
Re: [Dovecot] OpenBSD and too many open files
On Aug 1, 2007, at 11:09 AM, Quentin Garnier wrote: Well, the problem is Christos did some other stuff in that commit than just fixing the bug. Try the attached patch. Thank you for the patch. It applied cleanly and I have a kernel that reflects the patch running right now. So far so good. I will report back if anything unusual happens. Otherwise, I will report back first thing next week if everything works fine from here on out. Thank you all for your help. Bryan
[Dovecot] Resend: How do I configure sendmail to accept emails for dovecot when dovecot has sql auth/user db.
Apologies for resending this, I am not sure it made it through the
first time..
---
Included below are my config files: sendmail.mc, dovecot.m4,
dovecot.conf, dovecot-sql.conf. Whenever I try to send email into
this system, it rejects it with user does not exist, however, the
user does exist as far as dovecot (imap) is concerned, it is in the
database.
THANKS - Yossie
# for i in /etc/dovecot/dovecot.conf /etc/dovecot/dovecot-sql.conf /
usr/share/sendmail-cf/mailer/dovecot.m4 /etc/mail/sendmail.mc; do
echo FILE: $i; echo ===; echo ; egrep -v '^ *(#|$)' $i; echo ;
echo ; done
FILE: /etc/dovecot/dovecot.conf
===
listen = [::]
disable_plaintext_auth = no
ssl_disable = yes
ssl_cert_file = /etc/ssl/dovecot/server.pem
ssl_key_file = /etc/ssl/dovecot/server.key
mail_location = maildir:~/.maildir
namespace private {
separator = .
inbox = yes
hidden = no
}
namespace private {
separator = .
prefix = INBOX.
inbox = no
hidden = yes
}
first_valid_uid = 0
protocol imap {
}
protocol pop3 {
}
protocol lda {
postmaster_address = [EMAIL PROTECTED]
main_plugin_dir = /usr/lib/dovecot/lda
mail_plugins = cmusieve quota
}
auth default {
mechanisms = plain
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
user = root
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0666
}
client {
path = /var/run/dovecot/auth-client
mode = 0666
}
}
}
dict {
}
plugin {
}
FILE: /etc/dovecot/dovecot-sql.conf
===
driver = mysql
connect = host=localhost dbname=dovecot user=root
default_pass_scheme = PLAIN
password_query = SELECT userPassword as password, user, concat(/var/
spool/dovecot/,substr(user,1,1),/user/,user) as userdb_home, 97 as
userdb_uid, 97 as userdb_gid FROM authdb WHERE user = '%n' and
userPassword = '%w'
user_query = SELECT concat(/var/spool/imap/,substr(user,1,1),/
user/,user) as home, 97 as uid, 97 as gid FROM authdb WHERE user = '%n'
FILE: /usr/share/sendmail-cf/mailer/dovecot.m4
===
Mdovecot, P=/usr/libexec/dovecot/deliver, F=DFMPhnu9,
S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,
T=DNS/RFC822/X-Unix,
A=deliver -d $u
FILE: /etc/mail/sendmail.mc
===
divert(-1)
dnl This is the macro config file used to generate the /etc/sendmail.cf
dnl file. If you modify the file you will have to regenerate the
dnl /etc/sendmail.cf by running this macro config through the m4
dnl preprocessor:
dnl
dnlm4 /etc/mail/sendmail.mc /etc/mail/sendmail.cf
dnl
dnl You will need to have the sendmail-cf package installed for this to
dnl work.
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
define(`confDEF_USER_ID',``mail:mail'')dnl
OSTYPE(`linux')dnl
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dnl
define(`confALIAS_WAIT', `30')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
dnl define delivery mode: interactive, background, or queued
dnl define(`confDELIVERY_MODE', `i')
MASQUERADE_AS(`ford.qa.laszlosystems.com')dnl
FEATURE(`limited_masquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(mailertable)dnl
dnl virtusertable: redirect incoming mail to virtual domain to
particular user or domain
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
dnl genericstable: rewrite sender address for outgoing mail
FEATURE(genericstable)dnl
FEATURE(always_add_domain)dnl
FEATURE(redirect)dnl
FEATURE(use_cw_file)dnl
FEATURE(local_procmail)dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`relay_based_on_MX')dnl
dnl FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see
http://www.mail-abuse.org/rbl/')dnl
dnl FEATURE(dnsbl, `dialups.mail-abuse.org', `Dialup - see http://
www.mail-abuse.org/dul/')dnl
dnl FEATURE(dnsbl, `relays.mail-abuse.org', `Open spam relay - see
http://www.mail-abuse.org/rss/')dnl
FEATURE(`delay_checks')dnl
FEATURE(`stickyhost')dnl
dnl SASL Configuration
dnl extract from http://www.sendmail.org/~ca/email/auth.html
dnl
dnl Next two lines are for SMTP Authentication
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
dnl
dnl Next line stops sendmail from allowing auth without encryption
define(`confAUTH_OPTIONS', `Apy')dnl
dnl
dnl STARTTLS configuration
dnl extract from http://www.sendmail.org/~ca/email/starttls.html
dnl
define(`CERT_DIR', `/etc/ssl/sendmail')dnl
define(`confCACERT_PATH', `CERT_DIR')dnl
define(`confCACERT', `CERT_DIR/CAcert.pem')dnl
define(`confSERVER_CERT', `CERT_DIR/MYcert.pem')dnl
define(`confSERVER_KEY', `CERT_DIR/MYkey.pem')dnl
define(`confCLIENT_CERT', `CERT_DIR/MYcert.pem')dnl
define(`confCLIENT_KEY', `CERT_DIR/MYkey.pem')dnl
dnl
dnl Uncomment next lines to hide identity of mail serve
Re: [Dovecot] Missing MIME-Version header in e-mails.
On Wed, August 1, 2007 8:36 pm, Tan Shao Yi [EMAIL PROTECTED] said:
Will it be possible to make this available in the 1.0 branch? UW-IMAP
seems to continue to process e-mails without the MIME-Version, so long as
it has the Content-Type or -Encoding header.
It's an easy patch if you want to apply it to your installation. Probably
something like this, although I haven't tried it...
src/lib-mail/message-parser.c @225:
- if (!hdr-eoh strcasecmp(hdr-name, Mime-Version) == 0) {
+ //if (!hdr-eoh strcasecmp(hdr-name, Mime-Version) == 0) {
/* it's MIME. Content-* headers are valid */
part-flags |= MESSAGE_PART_FLAG_IS_MIME;
- }
