Re: [Dovecot] Dovecot write activity (mostly 1.1.x)
On Sun, November 4, 2007 4:32 pm, Timo Sirainen wrote: I didn't know that mail_nfs_index=yes resulted in a forced chown. How come that's necessary with NFS but not on local disks? It's used to flush NFS attribute cache. Enabling it allows you to use multiple servers to access the same maildir at the same time while still having attribute cache enabled (v1.0 required actime=0). If you don't need this (and it's better if you don't), then just set the mail_nfs_* to no and it works faster. By the way I misinformed you about fsync_disable=yes. It was like that before i upgraded to v1.1, but v1.1 requires fsync_disable=no when mail_nfs_index=true so I had to disable it. So you use ZFS on the NFS server, but Dovecot is using NFS on client side? The fsyncs then just mean that the data is sent to NFS server, not a real fsync on ZFS. Thanks a lot for the help - this changed a lot! Dist writes fell to about 1/3 of before. I guess the reason is that ZFS can now make use if it's caching capabilities. Delivers activity is completely random since it's impossible to load balance a connection based on the e-mail recipient, since only the ip is known at the load balancing point. Therefore I have fsync_disable=no for deliver. It's easy to force the clients using imap/pop3 to the same server since it can be based on the ip only. Therefore I have fsync_disable=yes for imap/pop3. This changed everything. Now there's a real performance gain upgrading from 1.0.x to 1.1.x. About two or three times less disk activity overall (reads were already improved) for both reads and writes. Thats pretty neat!
Re: [Dovecot] Couldn't init INBOX: Can't sync mailbox: Messages keep getting expunged
On Sat, November 3, 2007 22:18, Timo Sirainen wrote: On Sat, 2007-11-03 at 14:20 +0100, Tom Sommer wrote: After updating Dovecot, From what version? I think it's related to the change in the cache files. I had a customer who couldn't see any mails in their inbox, what so ever - there were plenty of files in the cur/ folder though. After a bit of wtf is going on here, I removed the dovecot* files in the maildir, and then it worked fine. I think I will take the consequence and simply make a script to nuke all dovecot cache files in my maildir folders. // Tom
Re: [Dovecot] Sent vs Sent Items
Ed W wrote: Religious wars about which is best aside - some mail clients seem to default to using Sent Items folder for saving sent mail, and others (many) default to Sent. Seems that in the interests of compatibility and doing the right thing (tm) that a symlink from one folder to the other name would ensure that either default would give the same result (in a mixed client setup)? However, I wonder if someone has already written a plugin to do something simple like this? More generally I guess it's folder aliasing, so that Sent == Sent Items and perhaps there are also synonyms for Drafts/Templates? Anyone got any thoughts on this simple idea? (The prob with sym links is a) creating them at mailbox setup time and b) what happens when someone tries to delete the folder...) Cheers Ed W I agree it would be nice if the IMAP server could have an option to map a variety of folder names to a particular 'real' folder name. Not just Sent. I have also seen: Trash vs Deleted Items
Re: [Dovecot] Sent vs Sent Items
At 2:35 PM + 11/5/07, Daniel Watts wrote: Ed W wrote: Religious wars about which is best aside - some mail clients seem to default to using Sent Items folder for saving sent mail, and others (many) default to Sent. Seems that in the interests of compatibility and doing the right thing (tm) that a symlink from one folder to the other name would ensure that either default would give the same result (in a mixed client setup)? However, I wonder if someone has already written a plugin to do something simple like this? More generally I guess it's folder aliasing, so that Sent == Sent Items and perhaps there are also synonyms for Drafts/Templates? Anyone got any thoughts on this simple idea? (The prob with sym links is a) creating them at mailbox setup time and b) what happens when someone tries to delete the folder...) Cheers Ed W I agree it would be nice if the IMAP server could have an option to map a variety of folder names to a particular 'real' folder name. Not just Sent. I have also seen: Trash vs Deleted Items While we're making a list: 'Junk' vs. 'Junk E-mail' is a particular problematic case of client disagreement because some clients (e.g. Eudora, Outlook) work in ways that are Very Bad when they disagree on the final destination of probable spam. -- Bill Cole [EMAIL PROTECTED]
Re: [Dovecot] Sent vs Sent Items
On Monday November 05, 2007 at 09:37:12 (AM) Bill Cole wrote: While we're making a list: 'Junk' vs. 'Junk E-mail' is a particular problematic case of client disagreement because some clients (e.g. Eudora, Outlook) work in ways that are Very Bad when they disagree on the final destination of probable spam. Correct me if I am wrong; however, there is no RFC specifically detailing the naming of folders. If there is no specification in place, the author of a software application is pretty much free to do as they please. The interesting fact is that while you claim that clients like 'Eudora Outlook' are bad, the users of said clients might very well consider your choice of MUA to be inferior. Just my 2¢. -- Gerard A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? TOPIC: Posting Etiquette
Re: [Dovecot] Sent vs Sent Items
Gerard Seibert wrote: On Monday November 05, 2007 at 09:37:12 (AM) Bill Cole wrote: hile we're making a list: 'Junk' vs. 'Junk E-mail' is a particular problematic case of client disagreement because some clients (e.g. Eudora, Outlook) work in ways that are Very Bad when they disagree on the final destination of probable spam. Correct me if I am wrong; however, there is no RFC specifically detailing the naming of folders. Right If there is no specification in place, the author of a software application is pretty much free to do as they please. No, not relay - if there is no specification, things _must_ be configurable. Or don't call your software IMAP client. Call it Cyrus, MS Exchange or Lotus Domino client..., if it ads restrictions where thy don't apply. The interesting fact is that while you claim that clients like 'Eudora Outlook' are bad, the users of said clients might very well consider your choice of MUA to be inferior. Outlook Express have at less options to configure Sent items and Drafts alias. In Outlook you can specify only root namespace prefix. Just my 2¢. Anyway alias option would be good workaround for limited pseudo IMAPclients. Uldis.
Re: [Dovecot] Couldn't init INBOX: Can't sync mailbox: Messages keep getting expunged
On Mon, 5 Nov 2007, Tom Sommer wrote: On Sat, November 3, 2007 22:18, Timo Sirainen wrote: On Sat, 2007-11-03 at 14:20 +0100, Tom Sommer wrote: After updating Dovecot, From what version? I think it's related to the change in the cache files. I had a customer who couldn't see any mails in their inbox, what so ever - there were plenty of files in the cur/ folder though. It'd be way nice if Dovecot, upon detecting index etc. insanity, renamed the Dovecot index etc. to dovecot.index.bork and regenerated them. Of course, it may already do that and I've just not been paying attention. (-: -- Asheesh. -- As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie
[Dovecot] truncated messages / attachments
I am currently running dovecot-1.1.beta6 (at least beta5 also had the problem) Retrieving some messages via IMAP gets them truncated and it also happens with retrieving attachments (message is HTML part of multipart-alternative, attachments are at least some PDF files). A user reported she is rather sure one of the messages was ok, before moving it to some other folder. In the filesystem the messages are there in full length. It happens with Outlook as well as with Thunderbird. We're using Maildir. After upgrading from beta5 to beta6 I have removed all dovecot.index* files of a folder with a defect message. This didn't make a difference. (Thought it could be related to some indexing problem). Any one else seeing this? \Maex -- Markus Stumpf
Re: [Dovecot] truncated messages / attachments
On Mon, Nov 05, 2007 at 06:51:36PM +0100, Markus Stumpf wrote: In the filesystem the messages are there in full length. It happens with Outlook as well as with Thunderbird. We're using Maildir. *blush* Ok, please disregard my last post for now. It looks like it *could* be a leftover truncated message due to the append problems fixed in beta5. Looks like I have to look more deeply into this, to rule previous errors out. \Maex -- Markus Stumpf
[Dovecot] imap search/content-transfer-encoding assertion failed
When performing an imap search, I hit the following assertion failure: imap(vmail): Panic: file unichar.c: line 128 (uni_ucs4_to_utf8_c): assertion failed: (chr = 0x4000) imap(vmail): Error: Raw backtrace: /usr/lib/dovecot/imap [0x80c7f7f] - /usr/lib/dovecot/imap [0x80c7d6a] - /usr/lib/dovecot/imap [0x80d8616] - /usr/lib/dovecot/imap(uni_utf8_to_decomposed_titlecase+0x9f) [0x80d892f] - /usr/lib/dovecot/imap(message_decoder_decode_next_block+0x679) [0x80c46e9] - /usr/lib/dovecot/imap(message_search_more+0x3e) [0x80c2e8e] - /usr/lib/dovecot/imap(message_search_msg+0x72) [0x80c3012] - /usr/lib/dovecot/imap [0x8093f47] - /usr/lib/dovecot/imap [0x80b7719] - /usr/lib/dovecot/imap(mail_search_args_foreach+0x32) [0x80b77c2] - /usr/lib/dovecot/imap(index_storage_search_next_nonblock+0x243) [0x8093af3] - /usr/lib/dovecot/imap [0x805cdc7] - /usr/lib/dovecot/imap [0x805d138] - /usr/lib/dovecot/imap(io_loop_handle_timeouts+0x112) [0x80ce892] - /usr/lib/dovecot/imap(io_loop_handler_run+0x66) [0x80cf316] - /usr/lib/dovecot/imap(io_loop_run+0x28) [0x80ce768] - /usr/lib/dovecot/imap(main+0x4ab) [0x806675b] - /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7e68ea8] - /usr/lib/dovecot/imap [0x8059141] My quick analysis: This seemed to be caused by a single message in this mailbox. I think dovecot is expanding base64 encoded binary data and then inevitably failing on the utf8 conversion of the decoded random binary data. The mime headers for this message are: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=080305000603070709090808 ... This is a multi-part message in MIME format. --080305000603070709090808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit text content ... --080305000603070709090808 Content-Type: application/x-zip-compressed; name=.zip Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=.zip base64 encoded zip file ... --080305000603070709090808-- # dovecot -n # 1.1.beta6: /etc/dovecot/dovecot.conf protocols: imap pop3 listen: 127.0.0.1 disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no first_valid_uid: 89 mail_location: maildir:~/Maildir mail_debug: yes mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mail_executable(default): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/rawlog /usr/lib/dovecot/pop3 mail_plugins(default): fts fts_lucene mail_plugins(imap): fts fts_lucene mail_plugins(pop3): quota mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 mail_log_prefix: %Us(%u[%r]): mail_log_max_lines_per_sec: 100 pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %f auth default: mechanisms: plain cram-md5 verbose: yes debug: yes debug_passwords: yes passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: fts: lucene
Re: [Dovecot] Sent vs Sent Items
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 5 Nov 2007, Bill Cole wrote: The problem is not what Eudora does with 'Junk' or what Outlook does with 'Junk E-mail', but what the two of them end up doing to each other's junk when they are both looking at an IMAP account that has both folders. I do have the same problem. I also want to globally set up some scripts and default filtering of SPAM (in particular). However, it is not as easy as to have two or more names for one physical folder: a) You want to show up just one of them - depending on the connecting MUA. b) There are MUAs using localized mailbox names. This is as much crap as the localized directories in Windows or the localized Re:. I dropped the idea of having two names for a pseudo-standard mail folder, instead each users must enter the particular mailbox names via Webinterface to let the scripts kick in. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRzAY+y9SORjhbDpvAQL/UwgAipm6qlSPjxdJuElTKlQnGvc2NRs+Z4wz aQqIxJhY2QzJ1fnGELNKI7MgRj55wws9NLcd2RJIg88mk48ipLu09pCtD5NHDODC /b5Ijnm/EzymUYvRjVDkBqzERiant9bF3ENfxljpqWsFKCuRRaGn7WD226LkADPd f708It47rKqyaZvlfIxgInRQHP+5APlgSIHgU9xC+WflTKp6jtm4yXnyypC0Aj3W /7f2uLPWvwIzgNT5cx3SVaoIbQ6HYE1/xDCvTzbf50Eq7jt4u8/pTicb9573/63M rCZHfNePZ/Rm0/CSR2I4BlMYXx62RLBxX9KhpRKov3JwAyYy2aoKRg== =CoOd -END PGP SIGNATURE-
