Re: [Dovecot] using 'socat' to relay Dovecot SASL's auth socket over TCP?
snowcrash wrote: > which, iiuc (?), can bidirectionally bridge the Dovecot unix-socket to > a TCP socket that Exim can talk/listen to. I've used socat extensively on a completely unrelated project in order to bridge UNIX domain sockets across machines. I assume you currently have this: exim -> /some/unix/socket -> dovecot-auth If you want to use socat, then make sure it is installed on both machines. You can bridge using ssh (recommended) or just plain TCP/IP. For ssh, run the following command on eximhost: socat -t 10 UNIX-LISTEN:/some/unix/socket,fork \ EXEC:"ssh [EMAIL PROTECTED] STDIO UNIX:/some/unix/socket" The ssh will need to be able to complete without any form of prompting (ie you need private/authorized keys setup). If you don't care about security then you can use TCP connections between the machines. On eximhost run this replacing with your chosen port number: socat -t 10 UNIX-LISTEN:/some/unix/socket,fork \ TCP4:dovecot-auth-host: On dovecot-auth-host run: socat TCP4-LISTEN:,fork \ UNIX:/some/unix/socket The -t 10 option waits for 10 seconds after one direction is closed before closing the other direction. The socat default is .5 seconds which I found problematic on higher latency links. Roger
Re: [Dovecot] Per user based protocol access and pause after failed login?
On Sun, 2007-06-17 at 01:16 +0300, Mart Pirita wrote:
> passdb pam {
> args = %s%c
> }
..
> But now even pop user can't login:(.
Oh, sorry. I forgot the %s%c doesn't work yet in 1.0.
So, the next possibility would be:
passdb passwd-file {
args = /etc/dovecot/deny.%Ls.%c
deny = yes
}
And create /etc/dovecot/deny.imap.secured and put users there. And place
that passdb before PAM.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] save failed to INBOX
On Sun, 2007-06-17 at 01:23 +0200, Erland Nylend wrote:
> On 2007-06-16, 01:36, Timo Sirainen wrote:
> > OK, attached is the next one. I actually found one missing error handler
> > from there. Doesn't matter if you keep the previous patch or not.
>
> Here's the first one:
>
> Jun 17 00:34:50 smtp1 deliver([EMAIL PROTECTED]): copy: mailbox_save_finish()
> failed
I still can't figure out why that would fail there.. Well, one more
patch that should tell where the error is.
diff -r b2fe5f3e5562 src/lib-storage/index/maildir/maildir-save.c
--- a/src/lib-storage/index/maildir/maildir-save.c Sat Jun 16 01:38:33 2007 +0300
+++ b/src/lib-storage/index/maildir/maildir-save.c Sun Jun 17 12:55:30 2007 +0300
@@ -384,6 +384,7 @@ int maildir_save_finish(struct mail_save
ctx->finished = TRUE;
if (ctx->failed && ctx->fd == -1) {
/* tmp file creation failed */
+ i_error("save_finish(): failed=true already");
return -1;
}
@@ -424,6 +425,8 @@ int maildir_save_finish(struct mail_save
if (ctx->failed) {
struct maildir_filename **fm;
+
+ i_error("save_finish(): finishing with failed=true");
/* delete the tmp file */
if (unlink(path) < 0 && errno != ENOENT) {
@@ -455,8 +458,10 @@ int maildir_save_finish(struct mail_save
if (dest_mail != NULL) {
i_assert(ctx->seq != 0);
- if (mail_set_seq(dest_mail, ctx->seq) < 0)
+ if (mail_set_seq(dest_mail, ctx->seq) < 0) {
+ i_error("save_finish(): mail_set_seq() failed");
return -1;
+ }
}
ctx->file_last = NULL;
diff -r b2fe5f3e5562 src/plugins/quota/quota-storage.c
--- a/src/plugins/quota/quota-storage.c Sat Jun 16 01:38:33 2007 +0300
+++ b/src/plugins/quota/quota-storage.c Sun Jun 17 12:56:29 2007 +0300
@@ -145,12 +145,16 @@ quota_copy(struct mailbox_transaction_co
copy_dest_mail = mail_alloc(t, MAIL_FETCH_PHYSICAL_SIZE, NULL);
qbox->save_hack = FALSE;
- if (qbox->super.copy(t, mail, flags, keywords, copy_dest_mail) < 0)
- return -1;
+ if (qbox->super.copy(t, mail, flags, keywords, copy_dest_mail) < 0) {
+ i_error("quota_copy(): super.copy failed");
+ return -1;
+ }
/* if copying used saving internally, we already checked the quota
and set qbox->save_hack = TRUE. */
ret = qbox->save_hack ? 0 : quota_check(t, copy_dest_mail);
+ if (ret < 0)
+ i_error("quota_check() failed");
if (copy_dest_mail != dest_mail)
mail_free(©_dest_mail);
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] subdir disappeared
On Wed, 2007-06-13 at 16:02 +0200, Luigi Rosa wrote: > I have an installation that sometimes acts strangely: > > Jun 12 11:28:00 mail dovecot: imap-login: Login: user=, > method=PLAIN, rip=10.10.10.103, lip=10.10.10.254 > Jun 12 11:53:59 mail dovecot: IMAP(nadia): > inotify_add_watch(/var/spool/mail/nadia/new) failed: No such file or > directory > Jun 12 11:53:59 mail dovecot: IMAP(nadia): > stat(/var/spool/mail/nadia/new) failed: No such file or directory > Jun 12 11:56:14 mail last message repeated 5 times > Jun 12 11:58:14 mail last message repeated 2 times > Jun 12 12:00:14 mail last message repeated 2 times > Jun 12 12:02:14 mail last message repeated 2 times > Jun 12 12:02:14 mail dovecot: IMAP(nadia): > stat(/var/spool/mail/nadia/new) failed: No such file or directory These pretty clearly say that the new/ directory doesn't exist. I've no idea why, but since that's the INBOX I can't think of a way Dovecot could cause this. > Jun 12 12:03:23 mail dovecot: IMAP(nadia): Disconnected: Logged out > . > Jun 13 12:08:01 mail dovecot: IMAP(nadia): > unlink(/var/spool/mail/nadia/cur/:2,ST) failed: Is a directory And here you for some reason have a "cur/:2,ST" directory. This sounds like the new/ directory was renamed to cur/:2, Dovecot recreates the new/ directory again so this problem fixed itself the next time the mailbox was selected. Except the :2,ST directory doesn't get deleted unless you delete it manually. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 60 seconds problem
On Sun, 2007-06-17 at 07:17 +0400, Waheed Rahuman wrote: > I am using Dovecot-1.0-0_27.rc10.e14. > > And when try to login with outlook there is an error > > saying "You server did not respond do u want to try again in 60 seconds" > > Any solutions please help http://wiki.dovecot.org/TestInstallation signature.asc Description: This is a digitally signed message part
Re: [Dovecot] save failed to INBOX
On Sat, 2007-06-16 at 22:20 +0200, Erland Nylend wrote: > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): > mailbox_transaction_commit() failed > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: > save failed to INBOX: Timeout while waiting for lock > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): > mailbox_transaction_commit() failed > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: > save failed to INBOX: Timeout while waiting for lock > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): > mailbox_transaction_commit() failed > Jun 15 09:24:13 smtp1 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: > save failed to INBOX: Timeout while waiting for lock > > Dont't know if it matters, but this account has 22000+ messages .. > The other one I saw with the same error message had 15000+. > > > BTW. What filesystem do you use? > > We're using GPFS. But it doesn't happen always I guess? Maybe this has something to do with GPFS? That error happens if maildir-uidlist.lock file was found to exist for two minutes + 2 seconds, and within those 2 minutes it changed at least once. The uidlist is locked while maildir is being synchronized. With local filesystems syncing a 22k maildir takes less than a second. I don't know with GPFS. You could try this with for example expunging a message and seeing how long it takes to return "OK". Or maybe GPFS caches uidlist.lock file's existence similar to NFS attribute cache? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] save failed to INBOX
On Sun, 2007-06-17 at 13:19 +0300, Timo Sirainen wrote: > The uidlist is locked while maildir is being synchronized. With local > filesystems syncing a 22k maildir takes less than a second. I don't know > with GPFS. You could try this with for example expunging a message and > seeing how long it takes to return "OK". Actually that might not be enough to trigger a full sync. Rather change cur/ directory's mtime and then do "NOOP" command. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot LDA munging INBOX access times?
On Fri, 2007-06-15 at 14:07 -0500, Steven F Siirila wrote: > > Hmm. I wonder how much of a timing window is left; this could be a viable > > option for us. However, I would like to consider our future options for > > mailbox formats other than mbox (we will eventually migrate I'm sure). > > For the mbox case (our immediate concern) your patch seems perfect, provided > that it is performing the read of the access time and the re-setting of the > access time during the time that the INBOX is locked. Timo, is this the case? That's right. > What we are considering doing is updating our local "mailattrd" to lock > using the same mechanism Dovecot is before reading the access time: > > lock /var/mail/user (open RDONLY, fcntl SETLKW) > stat /var/mail/user (to get last access time) > unlock /var/mail/user (close) > > Unfortunately, it is more overhead. But it should be 100% accurate. That should work. Or I guess you saw my other mail already too? That doesn't require creating the lock, but should be 100% accurate as well. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] subdir disappeared
Timo Sirainen said the following on 17/6/2007 12:06: These pretty clearly say that the new/ directory doesn't exist. I've no idea why, but since that's the INBOX I can't think of a way Dovecot could cause this. Neither I. I reported this issue because is VERY VERY strange. The Linux installation on server is quite simple, there are half a dozen users and nobody puts his hands on the server. What drives me mad is that I cannot reproduce the error, nor I can relat the error to anything. :( And here you for some reason have a "cur/:2,ST" directory. This sounds like the new/ directory was renamed to cur/:2, Dovecot recreates the new/ directory again so this problem fixed itself the next time the mailbox was selected. Except the :2,ST directory doesn't get deleted unless you delete it manually. BINGO! Your evaluation of the situation is 100% exact. The annoying side of this situation is that the mailbox is unusable until the :2,ST directory is removed. I am going to install 1.0.1, I hope that the things will get better. Ciao, luigi -- / +--[Luigi Rosa]-- \ F u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
Re: [Dovecot] save failed to INBOX
On 2007-06-17, 12:59, Timo Sirainen wrote: > On Sun, 2007-06-17 at 01:23 +0200, Erland Nylend wrote: > > On 2007-06-16, 01:36, Timo Sirainen wrote: > > > OK, attached is the next one. I actually found one missing error handler > > > from there. Doesn't matter if you keep the previous patch or not. > > > > Here's the first one: > > > > Jun 17 00:34:50 smtp1 deliver([EMAIL PROTECTED]): copy: > > mailbox_save_finish() failed > > I still can't figure out why that would fail there.. Well, one more > patch that should tell where the error is. Hereby added :) -- Erland Nylend
Re: [Dovecot] save failed to INBOX
On 2007-06-17, 13:19, Timo Sirainen wrote: > But it doesn't happen always I guess? No. The accounts receive most of the deliveries just fine. Then inbetween the successful deliveries, some fail with that error message. > Maybe this has something to do with GPFS? Could be. I'm not sure. > That error happens if maildir-uidlist.lock file was found to exist for > two minutes + 2 seconds, and within those 2 minutes it changed at least > once. > > The uidlist is locked while maildir is being synchronized. With > local filesystems syncing a 22k maildir takes less than a second. > I don't know with GPFS. You could try this with for example > expunging a message and seeing how long it takes to return "OK". Using thunderbird, expurging a message seems to work just fine, and it takes less than a second. > Or maybe GPFS caches uidlist.lock file's existence similar to NFS > attribute cache? Could be something like that. -- Erland Nylend
Re: [Dovecot] save failed to INBOX
On 2007-06-17, 13:21, Timo Sirainen wrote: > On Sun, 2007-06-17 at 13:19 +0300, Timo Sirainen wrote: > > The uidlist is locked while maildir is being synchronized. With local > > filesystems syncing a 22k maildir takes less than a second. I don't know > > with GPFS. You could try this with for example expunging a message and > > seeing how long it takes to return "OK". > > Actually that might not be enough to trigger a full sync. Rather change > cur/ directory's mtime and then do "NOOP" command. I've tried doing: $ telnet my.mail.server 143 Trying 81.167.36.148... Connected to my.mail.server Escape character is '^]'. * OK Dovecot ready. # LOGIN [EMAIL PROTECTED] password # OK Logged in. # SELECT INBOX * FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk \*)] Flags permitted. * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1155059954] UIDs valid * OK [UIDNEXT 28796] Predicted next UID # OK [READ-WRITE] Select completed. # NOOP * 22809 EXISTS # OK NOOP completed. The NOOP typically takes up to 2 seconds if I "touch cur/foo" in the users maildir before sending the command. I noticed that it printed some output once, when I sent a NOOP: [...] * 2578 FETCH (FLAGS (NonJunk)) * 2579 FETCH (FLAGS (NonJunk)) * 2580 FETCH (FLAGS (NonJunk)) * 2581 FETCH (FLAGS (NonJunk)) * 2582 FETCH (FLAGS (NonJunk)) * 2583 FETCH (FLAGS (NonJunk)) * 2584 FETCH (FLAGS (NonJunk)) * 2585 FETCH (FLAGS (NonJunk)) * 2586 FETCH (FLAGS (NonJunk)) [...] It normally prints only: * 22809 EXISTS # OK NOOP completed. -- Erland Nylend
Re: [Dovecot] Binary packagers: BSD license issues
Adding this SHA256 code made me read the BSD license once again. It
says:
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
Then there are a few files from Cyrus as well which contain:
* 4. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*"This product includes software developed by Computing Services
* at Carnegie Mellon University (http://www.cmu.edu/computing/)."
And something similar in utc-mktime.c for Berkeley university as well. I
think I'd really like to get rid of those base64.c and utc-mktime.c
exceptions.. There's probably also an easier/faster way to implement
utc_mktime().
Currently these copyrights or acknowledgments aren't listed anywhere
else than in the source files. I don't know if binary packagers have
added those, but somehow I doubt it.
So I think I should add these to COPYING file somehow. Any suggestions?
I'm not the packager of dovecot for pkgsrc (NetBSD and others), but I do
package other things. From my viewpoint, 3-clause BSD license is really
no problem provided you have an installable and preferably installed
file.
4-clause BSD is a bit annoying but not that big a deal. But I don't
think it's compatible with LGPL. If you're still the only copyright
holder, you can of course make an exception that advertising clause is
ok.
What I would suggest is that you add a file doc/COPYRIGHT that has
whatever is necessary to satisfy all these things.
Then, have make install put it in
$(prefix)/share/doc/dovecot/COPYRIGHT
In pkgsrc right now, there are manual install rules:
post-install:
${INSTALL_DATA} ${WRKDIR}/dovecot-example.conf
${DESTDIR}${EGDIR}
${INSTALL_DATA} ${WRKSRC}/doc/dovecot-* ${DESTDIR}${EGDIR}
${INSTALL_SCRIPT} ${WRKDIR}/mkcert.sh ${DESTDIR}${EGDIR}
so adding a INSTALL_DATA for COPYRIGHT won't hurt at all.
I realize the doc dir is not necessarily the same; it would be nice to
have a --with-docdir to set it for the preference of various packaging
systems, but not a big deal.
Greg
Re: [Dovecot] index
(Ccing again the list in case someone else has similar problems) On Sun, 2007-06-17 at 20:14 +0200, Lucas -LandM- wrote: > Hi Timo, > >I patched the source and same result. We think the problem is because > everytime user access to his mailbox, dovecot do the index again. And it > consume near the 80% in iowait because, as strace shows, read all mails. The problem isn't that Dovecot indexes it. The problem is that Dovecot ISN'T indexing it. Dovecot commits changes to cache file only after a FETCH command finished successfully. So if the client is disconnected in the middle of doing the FETCH, all of the work that Dovecot did so far gets lost on Dovecot's side. And apparently your client also starts everything from the beginning, even though it already knew some of the messages' sizes.. So the previous patch I sent was supposed to prevent this because originally Dovecot was the one that disconnected the client. It logged "Disconnected for inactivity in reading our output" as the disconnect reason. This shouldn't happen anymore after you patched it, so why did the client still get disconnected? Anyway, here's another patch that makes Dovecot not forget all of its work if the client gets disconnected in the middle of FETCH: http://hg.dovecot.org/dovecot-1.0/rev/e1cd11c5e00a If the client is still disconnecting, it probably takes a couple of tries to get everything read and cached, but after that it should all work nicely. Here's a similar patch for POP3: http://hg.dovecot.org/dovecot-1.0/rev/86766f448e50 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.0.1 released
On Fri, Jun 15, 2007 at 07:55:32PM +0300, Timo Sirainen wrote: > http://dovecot.org/releases/dovecot-1.0.1.tar.gz > http://dovecot.org/releases/dovecot-1.0.1.tar.gz.sig > > Lots of small fixes. Packages for RHEL3,4,5 and FC5,6 and F7 are updated to 1.0.1: http://atrpms.net/name/dovecot/ > * deliver: If Return-Path doesn't contain user and domain, don't try > to bounce the mail (this is how it was supposed to work earlier too) > * deliver: %variables in mail setting coming from userdb aren't > expanded anymore (again how it should have worked). The expansion > could have caused problems if paths contained any '%' characters. > > + Print Dovecot version number with dovecot -n and -a > + deliver: Added -e parameter to write rejection error to stderr and > exit with EX_NOPERM instead of sending the rejection by executing > sendmail. > + dovecot --log-error logs now a warning, an error and a fatal > - Trying to start Dovecot while it's already running doesn't anymore > wipe out login_dir and break the running Dovecot. > - maildir: Fixed "UID larger than next_uid" errors which happened > sometimes when dovecot-uidlist file didn't exist but index files did > (usually because mailbox didn't have any messages when it was > selected for the first time) > - maildir: We violated maildir spec a bit by not having keyword > characters sorted in the filename. > - maildir: If we don't have write access to cur/ directory, treat the > mailbox as read-only. This fixes some internal error problems with > trying to use read-only maildirs. > - maildir: Deleting a symlinked maildir failed with internal error. > - mbox: pop3_uidl_format=%m wasn't working right > - mbox: If non-filesystem quota was enabled, we could have failed > with "Unexpectedly lost From-line" errors while saving new messages > - mysql auth: %c didn't work. Patch by Andrey Panin > - APPEND / SEARCH: If internaldate was outside valid value for time_t, > we returned BAD error for APPEND and SEARCH never matched. With 64bit > systems this shouldn't have happened. With 32bit systems the valid > range is usually for years 1902..2037. > - COPY: We sent "Hang in there.." too early sometimes and checked it > too often (didn't break anything, but was slower than needed). > - deliver: Postfix's sendmail binary wasn't working with mail_debug=yes > - Don't corrupt ssl-parameters.dat files when running multiple Dovecot > instances. > - Cache compression caused dovecot.index.cache to be completely deleted > with big endian CPUs if 64bit file offsets were used (default) > - Fixed "(index_mail_parse_header): assertion failed" crash > -- Axel.Thimm at ATrpms.net pgpT6JfpZ3HtI.pgp Description: PGP signature
[Dovecot] ?? Error: child 1064 (imap) killed with signal 4
After noticing a commit to the HG repository, http://hg.dovecot.org/dovecot-1.0/rev/f88b1e225be5 about, " We didn't update last_output timestamp with long fetches, causing Dovecot to idle-disconnect the client." I chekced out the latest from the DOVECOT-1.0 repo, and built again. Unfortunately, this problem still exists. Login simply disconnects. Any help, anyone? -- Ben
Re: [Dovecot] save failed to INBOX
On 2007-06-17, 17:52, Erland Nylend wrote: > On 2007-06-17, 12:59, Timo Sirainen wrote: > > On Sun, 2007-06-17 at 01:23 +0200, Erland Nylend wrote: > > > On 2007-06-16, 01:36, Timo Sirainen wrote: > > > > OK, attached is the next one. I actually found one missing error handler > > > > from there. Doesn't matter if you keep the previous patch or not. > > > > > > Here's the first one: > > > > > > Jun 17 00:34:50 smtp1 deliver([EMAIL PROTECTED]): copy: > > > mailbox_save_finish() failed > > > > I still can't figure out why that would fail there.. Well, one more > > patch that should tell where the error is. > > Hereby added :) Here are the resulting logs: Jun 17 20:06:35 smtp2 deliver([EMAIL PROTECTED]): copy: mailbox_save_finish() failed Jun 17 20:06:35 smtp2 deliver([EMAIL PROTECTED]): quota_copy(): super.copy failed Jun 17 20:06:35 smtp2 deliver([EMAIL PROTECTED]): mailbox_copy() failed Jun 17 20:06:35 smtp2 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: save failed to INBOX: Unknown error -- Erland Nylend
