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-
Re: [Dovecot] Sent vs Sent Items
At 12:01 PM -0500 11/5/07, Gerard Seibert wrote: 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, I think you misunderstood me, which is understandable given how I phrased it... the users of said clients might very well consider your choice of MUA to be inferior. 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. Guess how I'm familiar with this? :) -- Bill Cole [EMAIL PROTECTED]
[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 ... --080305000603070709090808 Content-Type: application/x-zip-compressed; name=".zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=".zip" ... --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
[Dovecot] MySQL-SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've been running dovecot authenticating against a local MySQL database, but it has come time to implement it with a remote database. Instead of using stunnel, I'd rather take advantage of MySQL's native SSL support. I didn't know if this was possible with dovecot, and if it was, what config changes I might need to get it going. I found the below page/patch from some time ago and tried to use the ssl_key and ssl_cert directives in /etc/dovecot-sql.conf, but it didn't seem to recognize them (perhaps I need to compile mysql-ssl support into dovecot manually?): http://www.dovecot.org/list/dovecot-cvs/2004-July/003003.html Also, I noticed a need for ssl_ca and ssl_ca_path but am unfamiliar with how to generate what's needed if these options are required. FYI, dovecot 1.0.7 is running on CentOS 4.5, using rpm from ATrpms: http://dl.atrpms.net/el4-i386/atrpms/stable/dovecot-1.0.7-0_63.el4.i386.rpm Thanks for any advice or documentation pointers you can provide. Have a great evening everyone! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL85sJ6p9X8nw/2oRAr9JAJ9u5XTOXqqUvVFE5HqEAr4HzC2juwCgob5o 7usezyZdBjP44wEYQKUg/fQ= =tv5y -END PGP SIGNATURE-
Re: [Dovecot] deliver to subfolder?
Ralf Hildebrandt wrote: Can dovecot's deliver deliver a mail to a certain subfolder within a user's mailbox? Yes, it can. I was thinking of something along the lines of: deliver -m subfolder But what is the correct syntax to deliver to "spam", subfolder of INBOX? deliver -m spam < message.txt deliver -m INBOX.spam < message.txt It depends on your configuration; by default "seperator = ." - thus "INBOX.spam" But..., if Sieve plugin is used, this location is used as the "keep" action's default value. Script can override/chage it. Uldis
[Dovecot] deliver to subfolder?
Can dovecot's deliver deliver a mail to a certain subfolder within a user's mailbox? I was thinking of something along the lines of: deliver -m subfolder But what is the correct syntax to deliver to "spam", subfolder of INBOX? deliver -m spam < message.txt deliver -m INBOX.spam < message.txt -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de
Re: [Dovecot] truncated messages / attachments
On Mon, 2007-11-05 at 18:51 +0100, Markus Stumpf wrote: > 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). Deleting dovecot.index.cache file and flushing clients' local cache probably fixes this for existing mails. I've heard of this before, but it hasn't happenned to me and I haven't been able to reproduce it.. signature.asc Description: This is a digitally signed message part
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] 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] 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
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 IMAP"clients. Uldis.
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
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
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] 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] 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!