Re: [Dovecot] 1.0.rc29 released
--On Saturday, March 31, 2007 9:32 AM +0200 John and Catherine Allen [EMAIL PROTECTED] wrote: - mind share in the boardroom is not the only possible goal for a project I was thinking of installed base, not commercial users per se.
[Dovecot] convert plugin failing
I'm struggling to get the convert plugin working using the Debian etch packages. When starting dovecot it was trying to create files in /.temp.hostname... convert-plugin.c looks like it has a couple of typos in it - it checks mail three times for NULL rather than mail, user, home. I changed this but it's getting called when these three items are set to: maildir:/HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB/Maildir dump-capability I must be missing something - shouldn't the mailboxes only be converted when a user logs in? Should the conversion be skipped for the dump-capability user (whatever that is!) Thanks, Adrian -- Adrian Bridgett - [EMAIL PROTECTED] GPG key available on public key servers
Re: [Dovecot] 1.0.rc29 released
On Saturday March 31, 2007 at 08:32:40 (AM) Jeff A. Earickson wrote: My one concern about dovecot is the feeping creaturism in the code. Why does it have to be an LDA? That is what procmail is for. And designing your own mailbox format (dbox?) seems dangerous too. I would have it stick to POP and IMAP, period. But then it is not my code either. It works great for IMAP, which is what I need. Personally, I like the LDA feature in Dovecot. Procmail is a memory hog with a cavorted rules configuration scheme. Its use has seriously declined in favor of better products now available. Procmail is best left to single user status. I would never consider employing it in a multi user environment, although I know it has been done. Why though I fail to understand. There are better and easier methods available. There is no inherent danger in designing your own inbox structure, provided that no other application attempts to access it incorrectly. Dovecot would not be the first LDA/POP/IMAP application to do this. -- Gerard A psychiatrist is a man who goes to a strip club and watches the audience. Merv Stockwood
Re: [Dovecot] 1.0.rc29 released
Dean Brooks [EMAIL PROTECTED] writes: I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. At the end of the day, the question is how to call it - if it's alpha, beta, rc, all have different needs. Yes, it should have been alpha or beta. OTOH, if you've tried to get people to test release candidates, that is hard enough. Most will silently wait for the real release ship when they next update their $DISTRIBUTION (and after that complain that from 0.99 to 1.0 the configuration file format changed, or something like that). So I still have some sympathy for Timo's many release candidates. I'd rather he called a broken release RC rather than have showstoppers in the actual release :-) Features aren't good in rc though. But let's wait how 1.0 looks before we complain :-) -- Matthias Andree
Re: [Dovecot] prefetch + static + deliver
On Fri, 2007-03-30 at 14:27 -0700, Tom Bombadil wrote: If you're using Dovecot's local delivery agent, you'll still need a valid userdb which it can use to locate the users. You can do this by adding a normal sql/ldap userdb after userdb prefetch. (http://wiki.dovecot.org/UserDatabase/Prefetch) My question is: Does it need to be a SQL/LDAP userdb? How about static or passwd? It doesn't *have* to be, but I think you're doing something very weird if imap/pop logins use SQL while deliver uses passwd.. And if you can use static as userdb, prefetch is pointless. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] convert plugin failing
On Sat, 2007-03-31 at 13:27 +0100, Adrian Bridgett wrote: I'm struggling to get the convert plugin working using the Debian etch packages. Does that mean v1.0.rc15? Convert plugin was pretty broken before rc28. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SQL mail storage - yes yes yes!
Timo Sirainen wrote: I wasted some time yesterday and today implementing a SQL storage plugin. It seems to be working, but: - Saving new messages is done in a regular INSERT statement, which is bad. PostgreSQL has at least this COPY TO command which could be used instead. - It breaks in stress testing - It's not that well optimized. Especially it could support caching some commonly requested fields (same as dovecot.index.cache file). - Currently works only with PostgreSQL. Nothing is committed to CVS yet. I'm not sure if I should even do that. I'm not sure if those lib-sql API changes were that great. Maybe there's a better way.. If you're interested in trying it, you need the latest CVS HEAD sources and these patches: http://dovecot.org/patches/sql-storage-changes.diff http://dovecot.org/patches/sql-storage-plugin.diff The SQL schema is in src/plugins/mail-sql/schema.sql file. It creates a tss named user by default, so you might want to modify that. :) Then set: mail_location = sql:pgsql:host=localhost dbname=mails user=mailuser password=foo mail_plugins = mail_sql I've been waiting till 1.0 came out to ask for new features like SQL. I don't think that SQL is a waste of time at all. In fact I believe that SQL is the future of email storage. SQL has a lot of advantages that will be tapped once people start using it. Yes - it is probably slower than mbox or maildir but you can make up for that with faster computers. SQL offers. Replication - the ability to have instant redundancy on multiple servers. The ability to undeliver messages - if the indexes are configured right, if you get a spam attack from an IP and after the attack you realize it was spam you can run a quick query and delete delivered email. Statistical advantages - admins can do email queries across all domains and all usersand all folders to gather useful information. An example might be to generate white list information that can be used for trusted email sources to bypass spam filtering and reduce false positives. Search Speed - should be a lot faster to search messages than maildir. And - there's probably a lot of things that will be realized once it's implemented because the indexing ability opens new posibilities. So - I definitely am someone who supports this idea. It will also make Dovecot stand out as a superior IMAP server. Go for it!
Re: [Dovecot] SQL mail storage - yes yes yes!
WRT size of the db, what about keeping just the message headers and indices in the db and the body as a file? Sounds very Outlook/$Exchange that... -- Juha http://www.geekzone.co.nz/juha
Re: [Dovecot] SQL mail storage - yes yes yes!
On Mar 31, 2007, at 11:36am, Stephen Lee wrote: On Sat, 2007-03-31 at 19:30 +0200, Martin Hudec wrote: snip Well imagine that we have 100 users in company, each of them has 200M mailbox usually filled at least to 150M. That gives us 15G database (I am not counting administrative overhead like indexes etc.). Martin WRT size of the db, what about keeping just the message headers and indices in the db and the body as a file? This is akin to some content management systems where the file info is in a db and the content resides as a file. Don't know what the logistics and performance issues are though. Clearly SQL mail storage is not for everyone. Stephen Or the whole message, but attachments could be removed and be stored as files. Just as clients have the option to store headers, full messages, and full messages + attachments. .tim
Re: [Dovecot] SQL mail storage - yes yes yes!
Stephen Lee wrote: On Sat, 2007-03-31 at 19:30 +0200, Martin Hudec wrote: snip Well imagine that we have 100 users in company, each of them has 200M mailbox usually filled at least to 150M. That gives us 15G database (I am not counting administrative overhead like indexes etc.). Lovely. What would such database solution require, for example running on MySQL (usual database for many of the small businesses out there), I cannot truly say now and I am afraid of it. It would be a hard beast. In terms of maintenance and also of resources requirements. When using mail server with maildir/mailbox we have two components: mail server software alone and disk subsystem. When using database we would get mail server software plus database software and disk subsystem. Thus introducing new component with new unknown behaviors in certain situations. Martin WRT size of the db, what about keeping just the message headers and indices in the db and the body as a file? This is akin to some content management systems where the file info is in a db and the content resides as a file. Don't know what the logistics and performance issues are though. Clearly SQL mail storage is not for everyone. Stephen Of course it's not for everyone. mbox wins for quick, small, and simple. MySQL would be for those who need what SQL offers. There's lots of features in Dovecot that I don't use, but I'm glad are in there.
Re: [Dovecot] 1.0.rc29 released
At 8:32 AM -0400 3/31/07, Jeff A. Earickson wrote: On Fri, 30 Mar 2007, Frank Cusack wrote: FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me. 1.0 = shit is almost always true for payware IMHO. Open source has a far better track record on this. If I had to give dovecot a version number right now, I would say it is about version 9.8. My one concern about dovecot is the feeping creaturism in the code. Why does it have to be an LDA? That is what procmail is for. That specific case is a very good thing. Procmail is not a good piece of software to rely on and offer to users as their filtering tool. -- Bill Cole [EMAIL PROTECTED]
Re: [Dovecot] SQL mail storage - yes yes yes!
On 3/31/2007 Stephen Lee wrote: WRT size of the db, what about keeping just the message headers and indices in the db and the body as a file? This is akin to some content management systems where the file info is in a db and the content resides as a file. Don't know what the logistics and performance issues are though. Clearly SQL mail storage is not for everyone. One of the biggest advantages I can think of is single instance storage. Break the message into its constituent parts (headers, body, attachments), and now you can forget about the idiots that send a 15MB attachment to everyone in the company - resulting in 523 copies of that attachment in the mail system - with SQL storage (done right) - you only have one copy - 15MB instead of 523 x 15MB. Timo? Can you elaborate on how thi sis implemented? Is the message broken up into parts? How hard would it be to implement single instance storage if an SQL db is used for the storage? Thanks for all your efforts! Charles
Re: [Dovecot] SQL mail storage - yes yes yes!
Charles Marcus wrote: On 3/31/2007 Stephen Lee wrote: WRT size of the db, what about keeping just the message headers and indices in the db and the body as a file? This is akin to some content management systems where the file info is in a db and the content resides as a file. Don't know what the logistics and performance issues are though. Clearly SQL mail storage is not for everyone. One of the biggest advantages I can think of is single instance storage. Break the message into its constituent parts (headers, body, attachments), and now you can forget about the idiots that send a 15MB attachment to everyone in the company - resulting in 523 copies of that attachment in the mail system - with SQL storage (done right) - you only have one copy - 15MB instead of 523 x 15MB. Timo? Can you elaborate on how thi sis implemented? Is the message broken up into parts? How hard would it be to implement single instance storage if an SQL db is used for the storage? Thanks for all your efforts! Charles That can be done without SQL as well as long as you're on a *nix system: with hard links. One of the reasons that's not usually done is that most MTAs split up the message in one copy per recipient before handing them to the LDA. At least I'm relatively sure that the splitting happens at MTA level. -- Jens Knoell Network Administrator *Surefoot, L.C.* 1500 Kearns Blvd. Suite A-100 Park City, UT 84060 Phone: (435) 655 8110 ext. 109 Fax: (435) 649 0663 Web: http://www.surefoot.com
[Dovecot] 1.0rc29: Corrupted index cache file
Hi, I have recently migrated from Courier to Dovecot, and I noticed a problem in one of my spam scripts. Here's the setup: Spam that needs to be retrained by the filter is placed in a maildir from the IMAP client. A cron job scans that maildir and if it finds a message, feeds it to the spam filter and removes it from the training maildir. Depending on whether or not the message was a spam or ham, it is either deleted or delivered to Inbox. It appears I am getting an error when the script deletes a mail message. I haven't checked if this message only occurs when a client is connected -- it's possible. Log excerpt: Mar 31 18:34:57 finity dovecot: IMAP([EMAIL PROTECTED]): Maildir /home/vmail/[EMAIL PROTECTED]/.Spam.Unsure sync: UID inserted in the middle of mailbox (8 3, file = msg.FHoB:2,) Mar 31 18:34:57 finity dovecot: IMAP([EMAIL PROTECTED]): Disconnected: Mailbox is in inconsistent state, please relogin. Mar 31 18:35:36 finity dovecot: IMAP([EMAIL PROTECTED]): Corrupted index cache file /home/vmail/[EMAIL PROTECTED]/.Spam.Unsure/dovecot.index.cache: indexid changed Jeff
Re: [Dovecot] SQL mail storage
hi. I'm sure this is on hold in your head, but just in case.. Can this be V2.0 minimum, please. Thanks, Ejay On Sat, 2007-03-31 at 17:34 +0300, Timo Sirainen wrote: I wasted some time yesterday and today implementing a SQL storage plugin. It seems to be working, but: - Saving new messages is done in a regular INSERT statement, which is bad. PostgreSQL has at least this COPY TO command which could be used instead. - It breaks in stress testing - It's not that well optimized. Especially it could support caching some commonly requested fields (same as dovecot.index.cache file). - Currently works only with PostgreSQL. Nothing is committed to CVS yet. I'm not sure if I should even do that. I'm not sure if those lib-sql API changes were that great. Maybe there's a better way.. If you're interested in trying it, you need the latest CVS HEAD sources and these patches: http://dovecot.org/patches/sql-storage-changes.diff http://dovecot.org/patches/sql-storage-plugin.diff The SQL schema is in src/plugins/mail-sql/schema.sql file. It creates a tss named user by default, so you might want to modify that. :) Then set: mail_location = sql:pgsql:host=localhost dbname=mails user=mailuser password=foo mail_plugins = mail_sql
Re: [Dovecot] 1.0rc29: Corrupted index cache file
On 1.4.2007, at 5.16, Jeff Rice wrote: Mar 31 18:34:57 finity dovecot: IMAP([EMAIL PROTECTED]): Maildir / home/vmail/[EMAIL PROTECTED]/.Spam.Unsure sync: UID inserted in the middle of mailbox (8 3, file = msg.FHoB:2,) http://wiki.dovecot.org/MailboxFormat/Maildir - Procmail problems PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] who owns dovecot files and dirs?
On 29.3.2007, at 22.50, Stewart Dean wrote: ...and what permissions should they have. I am thinking of /var/ run/dovecot and the index directory. What ownership, group and permissions should they be? Are there any other files/dirs created for dovecot alone (not the mail folders and INBOXes); if so, how should they be owned and permed? I had thought they were to be owned by dovecot, but it turns out that they should not Dovecot opens pretty much all the configuration etc. files as root before dropping the privileges. So in general they could all be 0600 owned by root. I don't think you should worry about that though. /var/ run/dovecot usually gets deleted at boot and Dovecot recreates them, so whatever permission changes you do to it they'll get erased anyway. /var/lib/dovecot then is currently created 0700, but it only contains ssl-parameters.dat which is public data. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] [ rc28 ] dict{} seems to be ignored
On 28.3.2007, at 11.38, Emiliano Gabrielli (aka AlberT) wrote: If you still can't get it to work, set mail_debug=yes and see if there's anything interesting in the logs. already done .. nothing and nothing ... I can see the login SQL queries .. I can see the quota fetched from the userdb_quota field ... but nothing about the quota update on the mysql storage ... dovecot updatets the maildir quota on the filesystem ... If it updates maildir quota, it sees quota=maildir setting somewhere. So since it's not in dovecot.conf, apparently it gets that from userdb's user_query? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] imaptest10 and stalled messages
On 30.3.2007, at 21.24, Mike Brudenell wrote: 2. How much real-life user load does running imaptest10 with 50 simulated clients equate to? I assume each simulated user is hammering away at its IMAP connection, so should equate to several (how many?) normal users in real-life operation? I don't know, but most IMAP connections are just idling, so it could be anything from 10-100x. 3. I'm concerned by the N/M number at the end of the imaptest10 output lines plummeting whenever one process goes into this stalled state: it almost suggests as if the only thing the other processes can do is logout? Are other sessions really being blocked, or is it just imaptest10 behaving like this? It's just imaptest. If it detects one connection stalling, it stops making new connections to the server until the stall goes away. That's however a good way to detect what it is that's stalling. Just wait for a while until there are only stalled connections, and you can truss the imap connections to see what they're doing. Are they waiting for some locks? PGP.sig Description: This is a digitally signed message part
