Re: [Dovecot] Mailing list's prefix
On 03/04/2010 03:59 PM, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. I vote to keep it. Although I filter on List-Id, occasionally my filters break and I end up receiving a bunch of list messages in my INBOX. When this happens, the first thing I do after fixing my filters is search for mailing list tags in subjects (because practically every mail client on earth supports doing so) and move those messages into the right place. One of the features I miss from claws-mail, now that I'm using Thunderbird again, is the ability to remove text matching an arbitrary regexp from all messages in a folder. I used to remove the [Dovecot] prefix using this, but since it was only hidden from view I still had the benefit of being able to search for it. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] UTF-8 mailbox names in filesystem
On Mon, 09 Nov 2009 21:11:23 -0500 Timo Sirainen t...@iki.fi wrote: Currently mailbox names are stored in IMAP's modified-UTF-7 format in filesystem. I was wondering about changing this in v2.0. The default would still be to use mUTF-7 in filesystem, but just adding :UTF8 or something to mail_location could enable UTF-8. Any thoughts? Could this be dangerous somehow? UTF-8 enables a lot of weird characters, perhaps no one really wants to see them on filesystem since there's no way to type the characters? But for small systems this probably isn't a problem. A while ago, I was playing around with the idea of encoded '/'s in Maildir names since many people have asked for a way to use them. UTF-7 does not require that each character be representable in only 1 way like UTF-8 does, so it's possible to encode US-ASCII characters and put them into the folder name; however, I found that most clients decode any mUTF-7 in folder names while parsing LIST/LSUB replies and then discard the name given by the server (expecting that they can just re-encode any non-ASCII characters and still arrive at the correct folder name.) While I would argue that these clients are buggy, the bug seems to be so common that encoding characters this way isn't practical. With that in mind, you do lose the ability to encode characters like this if the folder names on disk are UTF8, but that's not much of a loss anyway if UTF8 encoding is optional. So far as UTF-8 on the filesystem is concerned, I've been using UTF-8 in filenames on my personal systems for years now without any real issues. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] More effective mailbox fetching over high RTT link
On Sun, 09 Aug 2009 22:20:41 +0200 Andrzej Adam Filip andrzej.fi...@gmail.com wrote: Could you offer some suggestion how to fetch mailbox content over high RTT link (with negligible packet loss)? Currently I use IMAP+IDLE *but* it fails to use full available bandwidth due to high RTT and send command wait for response nature of POP3 and IMAP4 protocols. The entire purpose of the command tag in IMAP is to facilitate batching or concurrent commands. See RFC3501 section 5.5. It shouldn't be too difficult to batch requests for new messages, or even select all the new messages in one request for a single folder. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] Maildir files with mtime in the future
On Fri, 3 Apr 2009 01:14:47 +0200 Holger Weiss hol...@cis.fu-berlin.de wrote: I'd guess most backup software will include files with an mtime newer than the time of the previous backup in incremental backups. At least, Bacula[*] and Veritas NetBackup do it that way. Aren't IMAP messages supposed to be immutable? If the actual message is changed, it should reappear as a new file/message, and therefore be backed up because it didn't exist in the previous backup run. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] OT: Run Sieve On A Mailbox Manually
On Fri, 21 Nov 2008 23:51:11 -0500 Neil [EMAIL PROTECTED] wrote: (Apologies for being offtopic.) The subject basically says it all...does anyone know of a tool to run a sieve script on a mailbox (in particular, Maildirs) manually? Ideally, I'd like to do it without adding a bunch of new headers to the mail. So, could I just do a find (or for-loop, if it was just one maildir) command and pipe all the mails into deliver..? That should work fine, although Sieve won't know the envelope from or to. You can easily add the envelope to address on the command line if you want to use the same one for every message, but adding the envelope from is a little trickier -- the envelope from isn't standardized in Maildir, so you'll have to try to pull it from the message headers. If you want to run sieve on all the messages in an mbox file, you could use formail from procmail in place of your for loop (e.g. formail -s deliver mboxfile.) Thanks, Neil. -- Ben Winslow [EMAIL PROTECTED]
Re: [Dovecot] OT: Run Sieve On A Mailbox Manually
On Sat, 22 Nov 2008 14:48:40 -0500 Neil [EMAIL PROTECTED] wrote: Why would deliver need to know the envelope to/from ? It wouldn't just use the To: and From: headers? Sieve distinguishes between the envelope and message to/from. I filter some mailing lists on the envelope from, since it's usually always the same or in a fixed format. If none of your rules filter on the envelope from/to, you should be fine running deliver without that info. -- Ben Winslow [EMAIL PROTECTED]
Re: [Dovecot] Dovecot master process
On Wed, 12 Nov 2008 00:41:36 +0200 Timo Sirainen [EMAIL PROTECTED] wrote: On Nov 12, 2008, at 12:34 AM, Steven F Siirila wrote: 3) Closes file descriptor 2 (stderr). I'm not actually sure if you can do this using a shell script, might need to use something else. With bash, you can close fd 2 with 'exec 2-'. -- Ben Winslow [EMAIL PROTECTED]
[Dovecot] Renames across namespaces
Will Dovecot ever support renames across namespaces? I'm attempting to support mailboxes under INBOX for compatibility with Courier, which I'm trying to replace, while also supporting mailboxes with no prefix. I don't want to confuse new users (who aren't already subscribed to their mailboxes with the INBOX prefix) by listing the entire tree twice (parented at the root and at INBOX.) This configuration seems to provide what I want: mail_location: maildir:~/mail namespace: type: private separator: . prefix: INBOX. inbox: yes hidden: yes namespace: type: private separator: . list: yes subscriptions: yes ...except that, when a legacy user tries to delete a mailbox under INBOX, Thunderbird (at least) renames the mailbox to make it a child of Trash at the root, e.g.: tag123 RENAME INBOX.test Trash.test tag123 NO Can't rename mailbox to another storage type. I was a little surprised that it didn't work at first, since they're both using the same (default) mail_location, but I see why it doesn't work after looking at the code. Is there any chance cross-namespace (and even cross-storage _type_) wouldn't eventually be supported? (I guess that the big problem is making cross-type renames appear atomic to clients.) Is there a better way to do what I'm trying to do? -- Ben Winslow [EMAIL PROTECTED]
Re: [Dovecot] v1.1.3 release candidate
On Sun, 31 Aug 2008 08:40:34 +0300 Timo Sirainen [EMAIL PROTECTED] wrote: How were you able to create a when column? I only get syntax error if I try to do that. Just FYI, it's possible to use reserved words as column/table names in MySQL by quoting them with backticks, e.g.: ([EMAIL PROTECTED]) [test] CREATE TABLE `where` (`when` TIMESTAMP); Query OK, 0 rows affected (0.18 sec) ([EMAIL PROTECTED]) [test] SELECT * FROM `where`; Empty set (0.00 sec) The quoting isn't standard, though, and varies between DB backends. I know that MySQL uses backticks (`foo`), PostgreSQL uses double quotes (foo), and MS's DB products use square brackets ([foo]). It's probably not worth the trouble to have dovecot escape them as long as it's possible to quote items this way in the config file. -- Ben Winslow [EMAIL PROTECTED]
Re: [Dovecot] After upgrade from 1.0 to 1.1.1 my hidden private namespaces suddenly aren't hidden anymore...
Peter Eriksson wrote: Just upgraded my home mail server from version 1.0 to 1.1.1 and now I noticed that Thunderbird has started showing the 'hidden' namespaces (albeit greyed) for that server (see the attached JPG image)... What can I change to really make them hidden again? Try adding list = no to the configuration for each hidden namespace. - Peter
Re: [Dovecot] nfs_flush errors
Hans Wunsch wrote: I'm looking for some help with an nfs error that is filling our logs. I get a constant stream of these messages: Jul 8 10:47:08 servername dovecot: [ID 107833 mail.error] IMAP(username): nfs_flush_file_handle_cache_dir: rmdir(/var/mail) failed: Device busy What OS are your dovecot and NFS servers running? Is /var/mail (or whatever it may be symlinked to) an NFS mountpoint?
Re: [Dovecot] Resource temporarily unavailable
On Sat, 2007-10-27 at 18:11 +0300, Timo Sirainen wrote: So you've somewhere limited the number of processes for users. Debian has them in /etc/security/limits.conf. I'm not exactly sure what reads that file and how those limits are passed to kernel. The file is read and applied by pam_limits.so, which tells the kernel about the limits with setrlimit(2). -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SASL from remote server
On Mon, 2007-09-17 at 11:33 -0700, Daniel L. Miller wrote: Timo Sirainen wrote: On 17.9.2007, at 19.25, Daniel L. Miller wrote: Is there a way, using Dovecot and Postfix, to use SASL from a remote server? Since it appears the communication uses Unix sockets, does this mean it is restricted to local services only? Not directly, but there are programs that can do unix - tcp socket proxying. Maybe some day when dovecot-auth is separated into its own dovecot-sasl package that could be added. Do know any you'd recommend? Take a look at socat: http://www.dest-unreach.org/socat/ -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Dovecot] how to authenticate plain ???
On Thu, 2007-08-02 at 16:00 +0200, Steffen Brunk wrote: Hello list, my name is Steven and of course: I got a problem... we are using dovecot 0.99 because it´s the actual stable version for RedHat 4 Enterprise. You will save yourself a lot of trouble in the long run if you build a package of dovecot 1.0.x for yourself, or grab a pre-made package from e.g. atrpms. I am trying to authenticate using PLAIN but I don´t know how. what do I have to send after receiving the +-symbol? PLAIN auth expects usernameNULauthnameNULpassword encoded in base64. Usually, username and authname will be the same, and you probably won't need to worry about cases where they're different. One easy way to encode the authentication information (because of the embedded NULs) is to use perl on the command line, e.g.: perl -MMIME::Base64 -e 'print encode_base64(user\0user\0password)' An easier way to test various authentication mechanisms is with the imtest utility from Cyrus (packaged in cyrus21-clients in Debian and cyrus-imapd-utils on RHEL4.) The package containing the clients doesn't require you to actually install the Cyrus imap daemon, and it also contains smtptest, pop3test, and nntptest which are handy for testing other sorts of servers. Here's example output, so you can see exactly what's sent/received from the IMAP server (S: = server, C: = client, and after the 'Security strength factor' line, the session is connected to the terminal in much the same way as telnetting to the server.) ([EMAIL PROTECTED]:~) imtest localhost S: * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5 AUTH=NTLM] Server ready. C: C01 CAPABILITY S: * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5 AUTH=NTLM S: C01 OK Capability completed. C: A01 AUTHENTICATE PLAIN S: + Please enter your password: C: cmFpbgByYWluAGhlbGxvLGRvdmVjb3Qh S: A01 OK Logged in. Authenticated. Security strength factor: 0 0 logout * BYE Logging out 0 OK Logout completed. Connection closed. HTH, -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot.conf pop3_uidl_format
On Thu, 2007-07-05 at 13:33 +0200, Peter Eriksson wrote: # If you want UIDL compatibility with other POP3 servers, use: # UW's ipop3d : %08Xv%08Xu # NOTE: Nowadays this is required to be set explicitly, since the old # default was bad but it couldn't be changed without breaking existing # installations. %08Xu%08Xv will be the new default, so use it for new # installations. # pop3_uidl_format = %08Xu%08Xv Notice the *very* small difference in the format between UW's ipop3d and the ones mentioned a little bit below? IIRC, the difference is intentional -- I believe the stated reason was that the mail UID (%u) is more unique than UIDVALIDITY (%v), so the default format has the UID at the beginning just in case the client truncates the UIDL. -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Dovecot] mbox vs maildir
On Fri, 2007-06-29 at 13:56 -0400, Jesse C. Smillie wrote: Wow this is weird because I'm about to make this same jump next week! From what I'm reading so far the big draw back with mbox is the single file with all the emails in it. When you delete a message from that file the whole file has to be rewritten without that email in it. If the box is big enough that can be a serious drag on the server. We have been using Dovecot here all school year for Imap Pop3 with the Mbox format and when two or more people delete at the same time the utilization on my 3ware card shoots up. We bought the BBU unit for the 3ware so I could enable WRITE cache and that has helped tremendously. I thought this study in regards to speed was quite interesting: http://www.courier-mta.org/mbox-vs-maildir/ http://www.courier-mta.org/mbox-vs-maildir/ So far my testing conversion process has gone really well. I am surprised how easy it was to tell procmail to do MailDir instead and even the conversion process was super easy. For converting the old inbox and folders I am using the tool mb2md.pl from http://batleth.sapienti-sat.org/projects/mb2md/ I was having a really hard time figuring all of this out until I ran into this webpage: http://adam.rosi-kessel.org/weblog/2007/04/18/adams-super-simple-guide-to-mbox-maildir-conversion/ I know through namespaces you can do inbox in one type and other boxes in another type. I was initially thinking about doing all new stuff in maildir and still support the old ~/mail format. The setup seemed easy enough, but I figured in the long run I am shutting down the server for a few hours to do this so I mis well go all the way. The only thing I'm not sure of is what the best file system to keep this on. I have been keeping my home directories on ReiserFS for quite a while, but one of our tech thinks XFS would be good. All data I have right now tells me to stay ReiserFS though. Even Dovecot's own page says XFS may not be a wise choice. We've had good experiences with XFS, hosting ~40k mailboxes totalling ~400 GiB across 2 NFS fileservers (although we're not using dovecot for those users, yet) on hardware that's not particularly beefy by today's standards (and well below the specs you provided for your server.) I've also personally had terrible experiences on a couple of other systems with reiserfs -- especially when the FS became slightly corrupt (due to failing hardware or the power going out at *just* the right time), though performance wasn't that great either. All the systems I mention were/are using Maildir, and this is somewhat contrary to many benchmarks, but it's been working well for me. YMMV and all that rot. -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Dovecot] wiki.dovecot.org double-escapes capcha info
The capcha on wiki.dovecot.org seems to be double-escaping HTML entities in the informational message, such that the wiki displays Captcha to prevent wiki spam, write strongDovecot/strong here: [sic.] When I dutifully entered strongDovecot/strong, it didn't work, saying span class=errorYou didn't provide the correct captcha. Use the browser's Back button and try again, or register an account to avoid this./span [sic] It took a few minutes for me to realize what was going on and simply enter Dovecot for the capcha... -- Ben Winslow [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Return error instead of dying on time back skip?
On Fri, 11 May 2007 14:50:54 +0300 Timo Sirainen [EMAIL PROTECTED] wrote: The code already allows the clock to move backwards by 5 seconds without dying, so how horrible are the clocks in those computers? :) Clock drift of about 13 seconds/day (150 PPM) is (unfortunately) not uncommon, and 4-6 seconds/day (50-75 PPM) is about the norm for PC hardware in my experience. Of course, this is exactly the reason why you should run ntpd instead of ntpdate on a cron job (especially a once-per-day cron job...) -- Ben Winslow [EMAIL PROTECTED] pgpnpNGpF3cyV.pgp Description: PGP signature
Re: [Dovecot] New full text search indexer
On Fri, 13 Apr 2007 14:07:58 +0300 Timo Sirainen [EMAIL PROTECTED] wrote: gzip compression makes the uidlist still 25% smaller (total space 19,50%). It'd have to be used to compress the file in smaller blocks because zlib doesn't support quickly seeking inside the file. That would probably waste some space. I don't think it's worth the extra CPU time and complexity. If you want to try to glue in another implementation as a quick test, dictd (http://sourceforge.net/projects/dict) has a seekable gzip implementation (that produces reverse-compatible files to boot.) I haven't looked at the actual code to see how hairy it is or how tightly it's intertwined with the rest of dictd, though. The manual page for dictzip has some details on the implementation. -- Ben Winslow [EMAIL PROTECTED] pgpbzoHlsVIaO.pgp Description: PGP signature
