Re: [Dovecot] v1.1.8 released
On Wed, Jan 07, 2009 at 03:45:28PM -0500, Timo Sirainen wrote: http://dovecot.org/releases/1.1/dovecot-1.1.8.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.8.tar.gz.sig Most importantly mbox bugfixes. v1.1 should finally be as stable with mboxes as it was with v1.0. Hopefully we'll also soon have the first v1.2 beta release and the final v1.2.0 somewhat soon after that. Compiling Dovecot 1.1.8 under Solaris 8 using gcc 3.4.6 gives a final link error on dovecot-auth. Apparantely, unsetenv() isn't a universally available function? libtool: link: gcc -std=gnu99 -O0 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -o dovecot-auth auth.o auth-cache.o auth-client-connection.o auth-master-connection.o auth-master-listener.o auth-request.o auth-request-handler.o auth-stream.o auth-worker-client.o auth-worker-server.o db-sql.o db-passwd-file.o main.o mech.o mech-anonymous.o mech-plain.o mech-login.o mech-cram-md5.o mech-digest-md5.o mech-ntlm.o mech-otp.o mech-skey.o mech-rpa.o mech-apop.o mech-winbind.o otp-skey-common.o plain-common.o passdb.o passdb-blocking.o passdb-bsdauth.o passdb-cache.o passdb-checkpassword.o passdb-passwd.o passdb-passwd-file.o passdb-pam.o passdb-shadow.o passdb-sia.o passdb-vpopmail.o passdb-sql.o userdb.o userdb-blocking.o userdb-nss.o userdb-passwd.o userdb-passwd-file.o userdb-prefetch.o userdb-static.o userdb-vpopmail.o userdb-sql.o mech-gssapi.o db-ldap.o passdb-ldap.o userdb-ldap.o libpassword.a ../lib-settings/libsettings.a ../lib-ntlm/libntlm.a ../lib-otp/libotp.a ../lib-sql/libsql.a ../lib/liblib.a -lpam /usr/local/lib/libsqlite3.so -lz -ldl -lrt -lnsl -lsocket -R/usr/local/lib -R/usr/local/lib Undefined first referenced symbol in file unsetenv../lib/liblib.a(env-util.o) ld: fatal: Symbol referencing errors. No output written to dovecot-auth collect2: ld returned 1 exit status -- Dean Brooks d...@iglou.com
Re: [Dovecot] v1.1.8 released
On Thu, Jan 08, 2009 at 11:15:55AM -0500, Timo Sirainen wrote:
On Thu, 2009-01-08 at 11:00 -0500, Dean Brooks wrote:
On Wed, Jan 07, 2009 at 03:45:28PM -0500, Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.8.tar.gz
http://dovecot.org/releases/1.1/dovecot-1.1.8.tar.gz.sig
Most importantly mbox bugfixes. v1.1 should finally be as stable with
mboxes as it was with v1.0. Hopefully we'll also soon have the first
v1.2 beta release and the final v1.2.0 somewhat soon after that.
Compiling Dovecot 1.1.8 under Solaris 8 using gcc 3.4.6 gives a final
link error on dovecot-auth. Apparantely, unsetenv() isn't a
universally available function?
I'm not really sure how this could be handled best. I guess it would be
possible to implement our own environ variable handling but that would
be pretty ugly.. Or perhaps I could modify the deliver config parsing
code once again so that it wouldn't need to unset the environment.. With
the upcoming v1.3 none of this would be necessary..
I found similar code implementing unsetenv() in a perl module that
seems to do the same thing. Completely untested, but example follows.
void env_remove(const char *name)
{
int name_len;
extern char **environ;
char **envp;
name_len = strlen(name);
for (envp = environ; *envp != NULL; envp++) {
if (strncmp(name, *envp, name_len) == 0
(*envp)[name_len] == '=') {
free(*envp);
do {
envp[0] = envp[1];
} while (*envp++);
break;
}
}
}
--
Dean Brooks
d...@iglou.com
[Dovecot] 1.1.3 panics
Hi, Installed Dovecot 1.1.3 today and started receiving panic errors on a few of our users: dovecot: [ID 107833 mail.crit] Panic: IMAP(xx): file mail-index-transaction-view.c: line 204: unreached When I upgraded, I deleted all of our users index files so it started with a clean slate. We are running mbox format over NFS with fsquota plugin on Solaris 8. Here is output of dovecot -n: base_dir: /var/run/dovecot/ protocols: imap ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login login_user: daemon login_log_format_elements: user=%u ip=%r mail_max_userip_connections: 5 first_valid_uid: 100 last_valid_uid: 128000 mail_privileged_group: mail mail_location: mbox:~/Mail:INBOX=/var/mail/%u:INDEX=/var/indexes/local/%u mail_nfs_storage: yes mbox_write_locks: fcntl mbox_lock_timeout: 180 mbox_lazy_writes: no mail_plugins: quota imap_quota namespace: type: private separator: / inbox: yes list: yes subscriptions: yes namespace: type: private separator: / prefix: Mail/ hidden: yes subscriptions: yes auth default: mechanisms: plain login failure_delay: 5 debug: yes debug_passwords: yes passdb: driver: shadow userdb: driver: passwd plugin: quota: fs -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] POP3 dictionary attacks
On Fri, Aug 15, 2008 at 06:43:30PM -0300, Eduardo M KALINOWSKI wrote: Charles Marcus wrote: Dictionary attacks are a fact of life these days. Just install some kind of blocking on your firewall (fail2ban is a good one), and let it take care of the worst of it.. I wonder what they want by cracking a POP3 server. Read the user's mails? It's true POP3 passwords are almost always equal to SMTP ones (which is useful for spamming), but then why not try to crack the SMTP server directly? One reason is so that they can get SMTP AUTH information and then sell the username/password pairs to spammers. Open relays are much more rare nowadays, so having a legitimate pre-existing account that can be used for outbound spam is worth much more than opening a new hotmail or gmail account. Especially through smaller ISPs that may not have adequate outbound mail rate-limits in place. A single hijacked mail account through a small ISP without rate-limits can be used to send an incredible amount of spam before it's caught. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Dovecot 1.1.1 + zlib plugin + mbox crash
On Mon, Aug 04, 2008 at 02:26:50PM -0400, Timo Sirainen wrote: On Jul 24, 2008, at 1:11 PM, Dean Brooks wrote: I cannot get Dovecot 1.1.2 to compile at all on Solaris8 with gcc 3.3.4 and newly recompiled versions of bzip2 and zlib libraries. This is the first time I've ever had a problem getting Dovecot to compile under Solaris 8. .. unknown 0x3ab8 /usr/local/lib/ libbz2.a(decompress.o) I think the problem is you're trying to link libbz2.a instead of libbz2.so (you didn't build the .so at all?). When building the bz2 library from source, the .so shared library is not built by default. It also appears that when forcing the shared library of libbz2 to be built, the compile process fails under Solaris8 without some sort of modifications. Ugh. Does dovecot require a shared version of the libbz2 library to compile correctly? Is there no way to statically link this? Or, alternatively, is there a way to shut off this libbz2 plugin completely in the configure script? -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] nfs_flush errors
On Thu, Jul 10, 2008 at 05:20:21PM -0700, Hans Wunsch wrote: Message: 7 Date: Wed, 09 Jul 2008 09:30:13 -0400 From: Ben Winslow [EMAIL PROTECTED] Subject: Re: [Dovecot] nfs_flush errors To: dovecot@dovecot.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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? We're on Solaris 10x86 mounting /var/mail from another Solaris 10 hosts via NFS4. Yes, /var/mail is an NFS. These are the mount options: mayor.ics.uci.edu:/mail_tank_001/spools - /var/mail nfs - yes rw,nosuid,hard,intr,bg,noac Are you using Dovecot version 1.1.1? If you are using an earlier version (i.e. a 1.1 release candidate), there was an update that was made that eliminited these errors in certain circumstances. Specifically under Solaris I might add. If you are using 1.1.1, I'll have to defer to others to solve the problem. I just remember running into those errors and having them disappear once I upgraded to a final release version. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] v1.1.rc13 released
On Fri, Jun 20, 2008 at 10:04:13PM +0200, Diego Liziero wrote: Any chance to have this assert converted to error as last patch before 1.1? Or am I the only one that is still getting this in rc13? I still get them in rc13, even after deleting the index files. We use mbox format with quota plugin. We've been getting them ever since release candidate 4 or so: Jun 21 09:32:08 sun1 dovecot: [ID 107833 mail.crit] Panic: IMAP(vr12): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(ibox-recent_flags, uid)) It only happens to the same users over and over, so its probably something in their client that is unusual, but I've never figured it out. -- Dean Brooks [EMAIL PROTECTED]
[Dovecot] Can't find next message offset
Hi, I am getting a lot of warnings since upgrading to 1.1rc10 (from rc4): mbox /home2/seta/Mail/Sent: Can't find next message offset for uid=12 Almost always, it is the Sent or Trash folders that are giving these. Users aren't experiencing any problems, but the errors continue to come. Is this something I should be concerned about? Here is output of dovecot -n: # 1.1.rc10: /usr/local/dovecot/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap login_dir: /var/run/dovecot//login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login login_user: daemon mail_max_userip_connections: 5 first_valid_uid: 100 last_valid_uid: 128000 mail_privileged_group: mail mail_location: mbox:~/Mail:INBOX=/var/mail/%u:INDEX=/var/indexes/local/%u mail_nfs_storage: yes mbox_write_locks: fcntl mbox_lock_timeout: 180 mbox_lazy_writes: no mail_plugins: quota imap_quota namespace: type: private separator: / inbox: yes list: yes subscriptions: yes namespace: type: private separator: / prefix: Mail/ hidden: yes subscriptions: yes auth default: mechanisms: plain login failure_delay: 5 debug: yes passdb: driver: shadow userdb: driver: passwd plugin: quota: fs -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Dovecot + iPhone
On Wed, Apr 23, 2008 at 11:59:29AM -0400, Tim Riley wrote: I want to start out by saying that Dovecot works 100% when viewing/moving mail (on our company mail server that I maintain) via Outlook Express and/or Windows Mail. I'm having issues with moving mail via my iPhone. If I move a message from my Inbox to another folder, the mail gets COPIED...not moved. So it exists in my Inbox as well as the folder I moved it to. When I test on my iPhone to Yahoo's mail server, the moved process works 100%. The iPhone does not expunge messages marked for deletion. If you are seeing the message still in your inbox, but with the \Deleted flag set, that is completely normal and is a feature/failure of the iPhone. It may be that Yahoo's mail servers automatically do an expunge upon disconnect even if not requested by the client. If you aren't seeing the \Deleted flag on the Inbox copy, then there may be some other issue at work, but it all works fine with our installation of 1.1rc4. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Dovecot + iPhone
On Wed, Apr 23, 2008 at 01:27:02PM -0400, Tim Riley wrote: Where do I check to make sure the /Deleted flag is set on the message in my Inbox? Well, one way is to look at the X-Status: header and see if it contains the letter D. As in: X-Status: D If it does, then it has been marked deleted by the client. Also, Can I configure Dovecot to function like Yahoo's server and expunge on disconnect? Not sure about that. There may be a plugin for it somewhere, but others on the list will know more about that. Expunging is normally up to the client to request though. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Dovecot + iPhone
On Wed, Apr 23, 2008 at 01:45:03PM -0700, Scott Silva wrote: on 4-23-2008 1:04 PM Tim Riley spake the following: I viewed the message left in the inbox and it does contain X-Status: D. So the flag is set. I'll call Apple tech support and see if there's a way to get the iPhone's mail client to expunge mail. I'm still interested in seeing if there's a plugin for Dovecot to expunge mail.so if anyone out there knows of oneI would really appreciate some direction. Thanks for the help! Microsoft's Outlook is similar in that it doesn't call an expunge automatically. Does the iPhone client have an expunge setting or a hidden button somewhere? There is a setting under Advanced options on the iPhone where you can Delete messages after XX days, but the lowest you can set it to is 1 day. I have no idea why there isn't an Immediately option. I'm also unsure if that is actually the expunge action, or if the phone is doing some sort of manual move to the Trash folder instead after that period of time. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] UID inserted in the middle of mailbox errors
On Fri, Mar 28, 2008 at 10:53:49AM -0400, Dean Brooks wrote: We are still getting, on a daily basis, users who cannot move messages to Trash or expunge Trash due to these errors: Mar 28 10:43:57 tm2 dovecot: [ID 107833 mail.error] IMAP(kss021): mbox sync: UID inserted in the middle of mailbox /home/kss021/Mail/Trash (3137 536, seq=2, idx_msgs=76) Our users have no other access to their mailbox other than Dovecot, and we are using mbox format and 1.1rc3. Deleting the indexes fixes the problem, so it seems to be a problem with index corruption and not something inherently wrong with the mailbox. That is, once I delete the index files, the problem does not come back immediately. I've seen others on the list with the same problem, but I wasn't able to find a workaround. It's happening more and more frequently. I guess what I don't understand is why Dovecot cant just mark the index invalid and purge it instead of failing over and over. I thought the whole point behind Dovecot's indexing is that it was able to detect index inconsistencies and mark the index invalid. For what it's worth, I set mbox_lazy_writes = no in dovecot.conf and the problem hasn't happened all weekend. Previously, it was happening hourly. It seems that there may be some lingering bugs in the lazy_write logic. If anyone is running into this problem on a regular basis, I would try disabling lazy writes and see if that helps. I'm not sure why everyone isn't having this problem given how such a stock vanilla configuration we're using, but maybe it's just related to server volume. -- Dean Brooks [EMAIL PROTECTED]
[Dovecot] UID inserted in the middle of mailbox errors
Hi, We are still getting, on a daily basis, users who cannot move messages to Trash or expunge Trash due to these errors: Mar 28 10:43:57 tm2 dovecot: [ID 107833 mail.error] IMAP(kss021): mbox sync: UID inserted in the middle of mailbox /home/kss021/Mail/Trash (3137 536, seq=2, idx_msgs=76) Our users have no other access to their mailbox other than Dovecot, and we are using mbox format and 1.1rc3. Deleting the indexes fixes the problem, so it seems to be a problem with index corruption and not something inherently wrong with the mailbox. That is, once I delete the index files, the problem does not come back immediately. I've seen others on the list with the same problem, but I wasn't able to find a workaround. It's happening more and more frequently. I guess what I don't understand is why Dovecot cant just mark the index invalid and purge it instead of failing over and over. I thought the whole point behind Dovecot's indexing is that it was able to detect index inconsistencies and mark the index invalid. Any help is much appreciated. Even a quick stopgap fix would be a lifesaver, short of a cronjob that just purges everyone's index files every 2 hours (which sort of defeats the point of using Dovecot). -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] dovecot-1.1.rc3 segmentation fault in fetch_bodystructure
On Tue, Mar 11, 2008 at 09:55:02AM +0100, Diego Liziero wrote: On Tue, Mar 11, 2008 at 9:09 AM, Timo Sirainen [EMAIL PROTECTED] wrote: Well, I'm not sure how you managed to cause this, but this should fix it: http://hg.dovecot.org/dovecot-1.1/rev/7e27d67d3abe Thank you Timo for the quick fix, here we have latest rc3 in a production environment. It has been used by over 600 users in the last 2 days. The most failing assertion (9694 times in 2 days) is the one I posted yesterday: Panic: IMAP(username): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(ibox-recent_flags, uid)) It happens when users are moving messages to Trash folder with thunderbird. The workaround for the user is to delete directly the messages without moving them to Trash. Today, we received several complaints about being unable to delete messages (by moving to Trash) not working, and discovered we were getting the same assertion failure as you: assertion failed: (seq_range_exists(ibox-recent_flags, uid)) The only client being used was Squirrelmail with no external access from any other client. Can you confirm that the patch Timo submited in the above link fixes this problem for 1.1rc3? If so, will this be committed for rc4 or beyond? -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] rmdir() warnings with 1.1.rc1
On Sun, Feb 24, 2008 at 02:57:32AM +0200, Timo Sirainen wrote: On Sat, 2008-02-23 at 13:17 -0500, Dean Brooks wrote: Looks like there are still some Solaris rmdir() warnings being logged to syslog in 1.1.rc1 in nfs_flush_file_handle_cache_dir(): Feb 23 13:09:51 sx3 dovecot: [ID 107833 mail.error] IMAP(ran04): \ nfs_flush_file_handle_cache_dir: rmdir(/var/mail) failed: Device busy Manual for rmdir on Solaris states: EBUSY The directory to be removed is the mount point for a mounted file system. We are using /var/mail mounted from NFS, which explains the EBUSY return code. So you have mbox INBOXes in /var/mail? Yep: mail_location = mbox:~/Mail:INBOX=/var/mail/%u:INDEX=/var/indexes/local/%u rmdir() is the only possibility and EBUSY doesn't flush it. But I'm beginning to think that maybe this can be fixed for mboxes without flushing the parent dir cache. mbox files in general don't get deleted, so the flushing is probably pretty useless. Ah, makes sense. The errors in syslog aren't causing any problems, but thought I'd mention it on the list since there's quite a few of them in the log. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Embedded From_ lines breaking Content-Length (and Dovecot)
On Tue, Jan 29, 2008 at 04:09:26AM +0100, Lennart Lvstrand wrote: I feel like I'm going totally crazy. Is it just me, or have embedded From_ lines really been breaking mbox messages since (at least) dovecot 1.0? It's trivial to reproduce too -- just mail yourself a message with a valid From_ line in it (assuming that your delivery system isn't doing From-escaping), or put it in a draft plain text message and save it. Then go and look in your Drafts folder... The mbox format, by definition, uses From_ lines as *the* separator. If it uses anything else, it's not conventional mbox format. There are variants of mbox, sometimes described as mboxcl2 that use Content-Length: as the defining separator, but that is *not* conventional mbox format. I'm sure others will clarify Dovecot's stance on this, but relying on Content-Length: headers as the sole source of determining message separation is VERY risky business unless you make absolutely sure that the values given are 100% correct and that all software touching the mailbox are also in agreement (i.e. POP daemons, UNIX readers, procmail, other IMAP daemons, etc.) Because Dovecot cannot control existing values of Content-Length headers, that seems to be an extremely risky proposition. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Delay on failed pw attempts
On Tue, Jan 01, 2008 at 11:21:50PM +, Stephen Usher wrote: Actually, a better method which would not inconvenience real users is to have an accumalative delay, i.e. the first error has a 1 second delay, the second 2 seconds, the third 4 seconds and so on. This should tar-pit any brute force attack, at least until the script kiddies just blast the server with a huge number of new connections to do the job. Unfortunately, most of the dictionary attacks that we've been seeing will open and attack multiple simultaneous connections. After a single attempt, they'll drop the connection and reconnect. The only way to mitigate the attacks is a long delay even on a single authentication failure. We can handle most of the load issue through our hardware load-balancers, but ultimately it's the delay after auth failure that is the only real limiting factor. Ideally, Dovecot would allow finer control over its process forking (specifically maximum simultaneous connections from a single IP, maximum total connections and maximum authentication attempts before disconnect), but I figured I'd probably be pushing my luck asking for all of it at once. :) Until those features are in place, larger sites have to just cross their fingers and hope that the current rash of attacks will slow over time. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] Delay on failed pw attempts
On Tue, Jan 01, 2008 at 03:46:23PM -0800, Asheesh Laroia wrote: On Tue, 1 Jan 2008, Dean Brooks wrote: Is there a way, or can a way be added, to add an auth_failed_delay=10s style option that would put in an artificial delay after a failed password attempt? As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans. But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool? Not everyone runs Linux (i.e. iptables) and Dovecot doesn't appear to have imbedded tcpwrappers support (i.e. forces you to run it under inetd which is not always desirable). One or the other is a prerequisite for fail2ban. Plus, I don't consider adding these features added complexity. On the contrary, I feel like ANY software that accepts incoming public TCP connections has an obligation to implement some basic controls to limit the resources it consumes. The lack of these kinds of controls are what result in most application-level DDOS attacks. In the case of IMAP or POP, a minimum of controls would be max connections, max connections per IP and max auth failures. Using a program to effectively tail -f a logfile in realtime is a hack. Logfile formats change, logfile locations change, not everyone uses syslog, etc. It also assumes that logfiles are stored in a centralized location which is often not the case in a large distributed network. Throw in network load-balancers in a server farm and something like fail2ban becomes a real headache. Hey, it's just my opinion, but keep in mind some people are running Dovecot in very large environments, and Linux isn't even anywhere in our equation. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] v1.1.beta11 released
On Sun, Dec 09, 2007 at 08:29:49PM +0200, Timo Sirainen wrote:
http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta11.tar.gz
http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta11.tar.gz.sig
This one should be the last beta release before the first v1.1 release
candidate.
Looks like the fix to Solaris dirent handling didn't make it into beta11.
Here is a recap of the problem:
This affects anyone under Solaris 8, and probably all other versions
of Solaris as well and breaks many mailbox LIST commands.
In src/lib-storage/list/mailbox-list-fs-iter.c, in the function
fs_list_dir_next(), the following code near the end of the function is
the culprit:
if (i_strocpy(dir-dirent.d_name, fname,
sizeof(dir-dirent.d_name)) 0) {
/* name too large.. shouldn't happen. */
continue;
}
To fix it, I changed it to:
if (i_strocpy(dir-dirent.d_name, fname, MAXNAMLEN) 0) {
/* name too large.. shouldn't happen. */
continue;
}
It appears that sizeof(dir-dirent.d_name) always returns 1 under
Solaris. This is a common dirent portability issue that affects a few
operating systems, including Solaris. I googled around and found
other authors who have done crazy stuff like this:
#ifdef BROKEN_ONE_BYTE_DIRENT_D_NAME
strcpy(dirent-d_name, filename, MAXPATHLEN);
#else
strcpy(dirent-d_name, filename, sizeof(dirent-d_name));
#endif
There is probably a cleaner way to deal with this though. From what I
can tell, this is the only place in Dovecot where a sizeof() is done
on d_name.
Unfortunately, Dovecot beta11 is not usable in a production
environment under Solaris until this issue is resolved.
--
Dean Brooks
[EMAIL PROTECTED]
Re: [Dovecot] v1.1.beta11 released
Hi, Since installing v1.1.beta11, I am now getting these errors in our syslog anytime I move messages between two folders: Dec 9 16:12:19 star dovecot: [ID 107833 mail.error] IMAP(dean): Cached message offset lost for seq 4 in mbox file /home/dean/Mail/Trash This was not happening with beta 10. It happens for all users on our system moving messages between any two folders. Removing the index files does not help. Here is output of dovecot -n, running under Solaris 8 (64 bit): base_dir: /var/run/dovecot/ protocols: imap ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable: /usr/local/adm/dovecot/libexec/dovecot/imap-login login_user: daemon mail_extra_groups: mail mail_location: mbox:~/Mail:INBOX=/var/mail/%u:INDEX=/var/indexes/local/%u mail_nfs_storage: yes mbox_write_locks: fcntl mail_plugins: quota imap_quota auth default: mechanisms: plain login passdb: driver: shadow userdb: driver: passwd plugin: quota: fs -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] LIST problem with Dovecot1.1beta10
On Tue, Dec 04, 2007 at 03:43:44PM +0200, Timo Sirainen wrote: On Mon, 2007-12-03 at 16:11 -0500, Dean Brooks wrote: a003 list Trash* * LIST (\NoInferiors \UnMarked) / Trash a003 OK List completed. Works here: x list Trash * LIST (\NoInferiors \Marked) / Trash x OK List completed. Show me your dovecot -n output? The output of dovecot -n follows. I confirmed that the problem is definitely different behavior than the old version we were running, although I'm confused how you couldn't be able to reproduce it. Well, I'm sure others will run into it if it's a configuration-specific thing, so it's probably worth checking into. I'll see if I can figure it out by twiddling with some settings. base_dir: /var/run/dovecot/ protocols: imap listen: 192.107.41.70 ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable: /usr/local/adm/dovecot/libexec/dovecot/imap-login login_user: daemon login_log_format_elements: user=%u ip=%r first_valid_uid: 100 last_valid_uid: 128000 mail_extra_groups: mail mail_location: mbox:%h/Mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/local/%u mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mbox_write_locks: fcntl mail_plugins: quota imap_quota auth default: mechanisms: plain login passdb: driver: shadow userdb: driver: passwd plugin: quota: fs -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] LIST problem with Dovecot1.1beta10
On Tue, Dec 04, 2007 at 03:43:44PM +0200, Timo Sirainen wrote: On Mon, 2007-12-03 at 16:11 -0500, Dean Brooks wrote: a003 list Trash* * LIST (\NoInferiors \UnMarked) / Trash a003 OK List completed. Works here: x list Trash * LIST (\NoInferiors \Marked) / Trash x OK List completed. Show me your dovecot -n output? Well, I confirmed that doing a specific LIST on INBOX works properly: x list INBOX * LIST (\NoInferiors \UnMarked) / INBOX x OK List completed. However, no matter what configuration changes I make, Dovecot refuses to list a filesystem mailbox unless you specify a wildcard: x list Sent x OK List completed. x list Sent* * LIST (\NoInferiors \UnMarked) / Sent x OK List completed. Were there any changes to the filesystem listing code? We're on NFS filesystem if it makes any difference. This problem practically makes Dovecot unusable. I've been trying to trace the code on this, but I'm having a hard time narrowing down what function is actually excluding individual files from the list. -- Dean Brooks [EMAIL PROTECTED]
[Dovecot] LIST problem with Dovecot1.1beta10
Hi, Certain IMAP folder problems started popping up with Squirrelmail with the 1.1beta10 version of Dovecot (and possibly earlier versions). Looked into it and I am seeing odd behavior with the LIST command. Here is how to reproduce problem, unless I'm missing something obvious: a001 login dean password a001 OK Logged in. a002 list * * LIST (\NoInferiors \UnMarked) / Sent * LIST (\NoInferiors \UnMarked) / Trash * LIST (\NoInferiors \UnMarked) / Drafts * LIST (\NoInferiors \UnMarked) / INBOX a002 OK List completed. a003 list Trash* * LIST (\NoInferiors \UnMarked) / Trash a003 OK List completed. a004 list Trash a004 OK List completed. *** What? Shouldn't it have listed Trash instead of returning nothing? a005 list Trash *** Unbalanced quote causes total lockup! It appears that Squirrelmail, and possibly others, are using the LIST command to test for the presence of a mailbox, but it seems impossible to get an exact match. Am I missing something here? -- Dean Brooks [EMAIL PROTECTED]
[Dovecot] Quick fix for nfs-workarounds.c
Hi, Under Solaris 8, the rmdir() command returns EEXIST instead of ENOTEMPTY if an rmdir() is attempted on a directory with files still in it. Dovecot 1.1beta9 currently gives tons of errors in the logfile as a result of the code not checking for the right error value. The function nfs_flush_file_handle_cache_dir() in nfs-worksarounds.c probably needs to reflect EEXIST as well as ENOTEMPTY. -- Dean Brooks [EMAIL PROTECTED]
[Dovecot] Dirsize quotas with 1.1beta9
Hi, Anyone able to get 'dirsize' quotas to work properly under 1.1beta9? I can get them to reflect the size of the INBOX properly, but it never seems to be adding up the size of the files in the folder directory itself. I'll keep hammering away at it if others are able to use dirsize with no problems, but wanted to check first. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] spf record
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT v=spf1 a -all Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use ?all in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information. Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] spf record
On Wed, Nov 28, 2007 at 11:45:29AM -0600, Rick Romero wrote: One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use ?all in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring. Well, perhaps, but that's not how it was originally designed to be used. I don't disagree that it has devolved into just another spam scoring device though. It's not even a very good one, since you can't easily determine if a message is simply being forwarded. As such, the score modifiers tend to be low. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. [snip] So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. 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. I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. -- Dean Brooks [EMAIL PROTECTED]
