--- a/dovecot/src/lib-index/mail-index-view.c
+++ b/dovecot/src/lib-index/mail-index-view.c
@@ -9,7 +9,7 @@
void mail_index_view_clone(struct mail_index_view *dest,
const struct mail_index_view *src)
{
- memset(dest, 0, sizeof(dest));
+ memset(dest, 0, sizeo
Line 776 of dovecot-2.0.15/src/lib-storage/index/maildir/maildir-sync-index.c
reads:
memcmp(old_rec, &new_rec, sizeof(old_rec)) != 0) {
Should that be sizeof(*old_rec)?
How do I configure dovecot-2.0.x to present a client SSL certificate when
proxying?
If dovecot on server1.example.com has:
passdb {
driver = static
args = proxy=y host=server2.example.com nopassword=y ssl=yes
}
and dovecot on server2.example.com has:
ssl_verify_client_cert = yes
auth_ssl_req
In 2.0.17 you increased LOGIN_MAX_INBUF_SIZE from 1024 to 4096.
Should you also have increased MASTER_AUTH_MAX_DATA_SIZE from (1024*2) to
(4096*2)?
/* This should be kept in sync with LOGIN_MAX_INBUF_SIZE. Multiply it by two
to make sure there's space to transfer the command tag */
I have been seeing this crash, which has been reported before but
apparently not yet resolved. As with the previous reporters, I do not
know how to reproduce it reliably.
Dovecot version: 1.1.rc5
Operating system: Mac OS X 10.5.2
CPU architecture: x86
File system: HFS+
Activity: From the ba
Some of my IMAP clients hang when connecting to Dovecot 1.1.rc5. I
believe the problem is that imap-login reads eagerly rather than
sparingly. If a client sends
a login user password
b select Inbox
all at once, without waiting for the login reply before sending the
select, imap-login eats
Hi, I found a typo on line 101 of dovecot-1.1.rc8/src/lib/failures.c.
The first two arguments to io_add() are reversed. The fd should be
first, and IO_WRITE second.
I see these errors more often than I'd like from Dovecot-1.1.2 on Mac
OS X 10.5.4 (names and numbers elided):
Corrupted index cache file %s: Corrupted virtual size for uid=%d: %d !
= %d
Corrupted index cache file %s: Broken virtual size for mail UID %d
Corrupted index cache file %s: used_file
One or more users?
Many different users.
Post your dovecot -n output?
Here's some of it. Not very enlightening.
# 1.1.2: /etc/dovecot/dovecot.conf
base_dir: /var/run/dovecot/
verbose_proctitle: yes
first_valid_uid: 6
last_valid_uid: 5
first_valid_gid: 6
last_valid_gid: 5
mail_access
How soon? With what kind of imaptest parameters? I can't reproduce
this on my Macbook (OS X 10.5.4, HFS+).
I ran imaptest for just a few minutes and saw all these errors in that
time. Default imaptest parameters except for user/host names etc.
Error: UIVALIDITY changed: %d -> %d
Did you
I re-ran imaptest on an empty mail store, single client, multiple
users, using your dovecot-crlf input file, for a couple hours. Here's
the distribution of errors that imaptest reports:
100 Error: user%d[%d]: <...>: Header DELIVERED-TO changed
167 Error: user%d[%d]: <...>: Header CC changed
Dovecot 1.1.2 crashes reliably for me now on a Mac OS X machine.
Here's some info:
--- Telnet session ---
$ telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
a login user1 password
a OK Logged in.
b select inbox
* FLAGS (\Answered \F
Panic: IMAP(user): file message-parser.c: line 684
(preparsed_parse_next_header_init): assertion failed: (ctx->part-
>physical_pos >= ctx->input->v_offset)
Linux 2.6.24-19-386
Maildir on ext3
Looks similar to but different from http://dovecot.org/list/dovecot/2008-June/031523.html
.
#0 0
After wondering for a while, I can now reproduce your problems. The
only
thing I had to do was to define WORDS_BIGENDIAN on a little-endian
machine. Why are you doing that? :)
Er, you're right. I built a "fat" (multi-architecture) Dovecot
executable on a big-endian PowerPC/MacOSX machine an
Running Dovecot-1.1.5, I see this assertion failure:
Panic: pop3-login: file sasl-server.c: line 75
(authenticate_callback): assertion failed: (client->auth_request ==
request)
Error: pop3-login: Raw backtrace:
2 pop3-login 0x0001ac41
default_fatal_finish
dovecot: Nov 24 12:49:06 Panic: IMAP(user): file ioloop-notify-
kqueue.c: line 66 (event_callback): assertion failed: (io->refcount ==
1)
dovecot: Nov 24 12:49:06 Error: IMAP(user): Raw backtrace:
2 imap0x000100068e82 default_fatal_finish + 41 ->
3 imap0x000100068eed i_sys
Is this random, common or reproducible?
Seen only once so far.
I guess it's possible that kqueue notifications are just completely
broken currently.
Oh, really?
Is this random, common or reproducible?
Seen only once so far.
Make that twice now, so it does seem to be reproducible.
Hello Dovecot developers,
Apple has made and tested significant changes to Dovecot v1.1 and now
is ready to contribute them back to your open source project. The
changes include:
Scalability and performance:
allow pop/imap mail processes to handle multiple clients
larger listen queues
Sta
Here are the first few simple patches from Apple, based on
dovecot-1.1.7. The comments with "APPLE" in them helped us merge in
your new releases; feel free to remove them. Please let me know if
you want subsequent patches in a different format, or if you have any
questions.
Patch #1. S
Patch 5 seems spurious to me, regardless of what Apple's lawyers want.
There are more substantial patches coming.
Patch #1. Some versions of Mac OS X have buggy CMSG_* macros.
Is the nopen() check really necessary?
It might detect buggy CMSG macros on non-Apple systems.
I'd like to know at least what kind of a bug it works around for
before applying it.
The 64-bit CMSG macros are broken in such a wa
Hmm. Actually I think when I was writing that code I noticed the same
thing and tried to fix it with:
/* there can be multiple events for a single io.
call the callback only once if that happens. */
if (io->refcount == 2 && io->io.callback != NUL
But it decreases the refcount every time.
So it does. You're right, simply removing the assert is probably
sufficient.
-#ifndef WORDS_BIGENDIAN
+#if !WORDS_BIGENDIAN
Is this change (and similar ones below) really necessary ?
Yes, since WORDS_BIGENDIAN is defined as __BIG_ENDIAN__ which is
always defined (either 0 or 1), not undef-or-1 like other parameters.
dovecot-auth already does internally a 0-2 second failure delay
The request for this feature specifically called for an increasing
backoff. As always, if you have a better way, go for it.
Here are a few more patches. Still keeping it easy for now. Again
the basis for these patches is dovecot-1.1.7.
Patch #6. Solve a cross-compilation endianness issue. Currently,
Dovecot assumes that the endianness of the build system is the same as
the endianness of the runtime system.
If you start renaming API functions, rename all of them for
consistency. :)
Agreed, but when changing code on a branch, minimizing code deltas
makes merging easier.
Your code disabled idle timeout entirely
Yeah, probably not a good idea. If I had realized that I probably
would have ju
I forwarded your comments to the original developer (of the code in
the patch). Waiting for a reply.
Do you have more patches?
Yes. I'm polishing patch 10 now which is substantial. There will be
one or two more tiny patches after that.
These are the last patches for now, and they're small. The base for
each of them is dovecot-1.1.7 + Apple patches 9 and 10, again not
because of a logical dependency but just because these patches change
parts of the earlier patches.
Patch #11 adds a few dtrace providers to key points in t
Also I thought that your patch would only put the same user's
connections to the same process.
Our aim was high scalability so we had to mix users on processes. We
are aware of the security implications.
I could see a trinary state for this: "off" for the current behavior,
"safe" for the
I don't see dtrace-dovecot.h included in it.
dtrace-dovecot.h is generated from dtrace-dovecot.d by the command
"dtrace -h -s $(DTRACE_SOURCE)" in src/lib/Makefile.am. See the
section "BUILDING CODE CONTAINING USDT PROBES" in http://developer.apple.com/documentation/Darwin/Reference/ManPage
the current code looks like it finds the first free connection_id
Actually connection_id's are increasing. The hash-lookup loop in
create_mail_process just prevents (extremely unlikely) duplicates when
next_connection_id wraps.
Following up.
You checked in slightly different versions of patches 1, 3 and 4 and
released them with 1.1.8. We will test your solutions for these and
adopt them if they work. Thanks!
For all the changes you checked into 1.1 on our behalf, will they also
be included in 1.2?
Following up.
You checked in a slightly different version of patch 6 and released it
with 1.1.8. We will test your solution for this and adopt it if it
works.
We will update our code to honor both the idle timeout and the auth
failure delay, to avoid the DoS situation you described, sinc
I think I'll release v1.2 without your patches.
Do you mean without patch 9 (the OD/SSL patch), or without any of our
patches? If the former, then OK, we understand. We're modifying our
OD support for dovecot anyway based on your detailed feedback.
On Jan 6, 2009, at 5:51 PM, I wrote:
Also I thought that your patch would only put the same user's
connections to the same process.
I could see a trinary state for this: "off" for the current
behavior, "safe" for the behavior you describe, and "max" for the
behavior in this patch.
FYI:
In reviewing the differences between 1.1.8 and 1.1.9 I saw a probable
bug in the new function uint_cmp() in src/lib-storage/index/maildir/
maildir-sync-index.c:
if (*i1 < *i2)
return -1;
else if (*i1 > *i2)
return -1;
else
Hi, we occasionally see this error message from
maildir_mail_set_cache_corrupted(): "Maildir filename has wrong W
value: %s/%s" but the path it prints is missing a component,
specifically, the new/cur/tmp component. For example:
/Volumes/Spool/user/maildir/12345.M123P123.example.com
sh
Fixed: http://hg.dovecot.org/dovecot-1.1/rev/c08c602ca0dc
Cool, thanks.
Are you using deliver?
Yup. The corrupted files actually contain dot-lock data
(pid:hostname) followed by a bunch of nulls. For instance, a mail
file with an S=3368 flag in the file name contains
"12345:mail.exam
I can set the log prefix for imap/pop3 processes using mail_log_prefix
but the log prefix for deliver is hard-coded. (I'm using 1.1.13.)
Deliver should either honor mail_log_prefix or have its own setting
(deliver_log_prefix?). What do you think?
My mail server consumed all of its configured file table slots and
started returning ENFILE ("Too many open files in system") for many
operations. This wreaked havoc with dovecot-1.1.13. Here are some
areas where dovecot should detect and more gracefully handle ENFILE
error returns:
1.
Seen this error a few times from dovecot-1.1.14, Mac OS X, 64-bit
Intel. NFS may have been used.
Panic: IMAP(user): file mail-index-sync-update.c: line 843
(mail_index_sync_map): assertion failed: (map->hdr.indexid == index-
>indexid || map->hdr.indexid == 0)
Two different backtraces to t
Seen this error a few times from dovecot-1.1.14, Mac OS X, 64-bit
Intel. Pretty sure NFS was not used.
Panic: IMAP(user): file index-sync.c: line 39
(index_mailbox_set_recent_uid): assertion failed:
seq_range_exists(&ibox->recent_flags, uid)
The backtrace is:
0 libSystem.B.dylib
Panic: IMAP(user): file mail-index-sync-update.c: line 843
(mail_index_sync_map): assertion failed: (map->hdr.indexid == index-
>indexid || map->hdr.indexid == 0)
Can you get the values of map->hdr.indexid and index->indexid?
Core dumps are now enabled so if it happens again I'll try to retr
Panic: IMAP(user): file index-sync.c: line 39
(index_mailbox_set_recent_uid): assertion failed:
seq_range_exists(&ibox->recent_flags, uid)
Did it log anything else?
Trying to find out.
Dovecot-1.1.14 on Mac OS X.
Panic: IMAP(user): file cmd-append.c: line 266
(cmd_append_continue_parsing): assertion failed: (ctx->count == uid2 -
uid1 + 1)
Trivially reproducible:
$ telnet mailserver 143
a login user password
b append inbox
Backtrace:
0 libSystem.B.dylib
This may resolve the mysterious "Maildir: Symlink destination doesn't exist"
errors.
--- a/src/lib-storage/index/maildir/maildir-util.c
+++ b/src/lib-storage/index/maildir/maildir-util.c
@@ -91,7 +91,7 @@
{
struct stat st;
- if (lstat(path, &st) == 0 && (st.st_mode & S_IFLNK) !=
First time I've seen this with dovecot-2.0.5. At 10:05 my auth server was
having problems and I saw this:
Thu Oct 14 10:05:32 server dovecot[3536]: lda: Error: userdb lookup(userX):
Request timed out
Thu Oct 14 10:05:32 server dovecot[3536]: lda: Fatal: Internal error occurred.
Refer to server
One system running dovecot-2.0.3 assert-crashed in a few ways recently. I know
2.0.3 < 2.0.5 but these have not been reported (or, presumably, fixed) since
2.0.3. Here are some logs:
Fri Oct 15 21:50:00 server3 dovecot[349]: lda(pid 349 user user10): Error:
Transaction log file /Volumes/mail/
When using the stats plugin for dovecot-2.0, UID commands that "continue" cause
infinite recursion and crash. For example, "A22 UID FETCH 151 BODY[]" when the
body is 3MB or so always crashes. For smaller messages, this command logs the
duration twice. Here is a patch to fix it:
--- stats-pl
Here's another one-off crash in dovecot-2.0.3's auth process. Looks like
request->mech == NULL in auth_request_initial(). I don't see any obvious fixes
to this code between 2.0.3 and 2.0.6 so it may still be present in 2.0.6.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVA
With service imap { client_limit = 5, service_count = 0 }, when the auth
process crashes the existing imap processes cannot reconnect to the auth-master
socket because they have long ago dropped root privileges. Is the right
solution to this:
(1) change the perms on the auth-master socket so pr
> Also note that because of a change in how (upcoming) v2.0.8 checks if
> imap/pop3/lmtp has been started from command line, version_ignore=yes is
> effectively always enabled for them when older master process is
> running.
I don't understand this. Can you please elaborate? Thanks.
Typo on line 292 of src/lib-master/master-login-auth.c in 2.0.8: tuah.
> It just seems to want to know if the current user is anonymous or not.
> http://hg.dovecot.org/dovecot-2.0/rev/c41ba33b8e16
OK, this looks plausible.
> Something similar could be done about submit_user too. Instead of
> sending "submit_user=x", send both "master_user=x" and "submit".
We chose
> when ACL plugin is loaded the master user by default has no permissions to
> any mailbox.
But without the ACL plugin a master user has all of the regular user's access,
including unlimited read/write/delete powers. Submit users don't because of
COMMAND_FLAG_OK_FOR_SUBMIT_USER.
> So if some
On Dec 5, 2010, at 11:17 PM, Timo Sirainen wrote:
> I don't think there's any need to send "anonymous_username" to imap
> process? It just seems to want to know if the current user is anonymous
> or not. That same thing has been in my TODO list for a while already
> because ManageSieve could use t
> Jan 17 12:06:20 server dovecot: imap(@YYY): Panic: file
> imap-client.c: line 570 (client_continue_pending_input): assertion failed:
> (!client->handling_input)
I just saw this with 2.0.8 too. Backtrace is:
0 __kill + 10
1abort + 177
20x10d928000 + 143594
30x10d928000 +
>> Jan 17 12:06:20 server dovecot: imap(@YYY): Panic: file
>> imap-client.c: line 570 (client_continue_pending_input): assertion failed:
>> (!client->handling_input)
I can reproduce this every time by sending any data in the same packet after
the "tag IDLE". For instance using nc:
$ nc
> I can't think of why any client would send IDLE+DONE in the same TCP packet.
Maybe not in the same packet, but network congestion or server overloading
could cause the IDLE and DONE to queue up together.
> Oh, that's nice.
Glad to help.
> Fixed now: http://hg.dovecot.org/dovecot-2.0/rev/4741
When I set imap_id_log=* in dovecot-2.0.11 and a client sends, say,
tag id ("a" "b" "c" "d")
then dovecot logs:
ID sent: a=b, b=c, c=d
The following patch makes it log instead:
ID sent: a=b, c=d
--- a/dovecot/src/lib-imap/imap-id.c(revision 113366)
+++ b/dovecot/src/lib
During a stress test dovecot-2.0.11 logs many warnings:
Mar 8 06:19:52 gromit dovecot[59204]: imap(pid 68864 user user15): Warning:
/Volumes/Mail/user15/dovecot-uidlist: Duplicate file entry at line 183:
1299556557.M571530P31883.gromit.example.com,S=21175,W=21549 (uid 67 -> 250)
Mar 8 06:20:10
> Can you easily reproduce this by running imaptest against a single user?
Nope. Any special imaptest arguments other than user=... pass=... host=...
mbox=...? I ran it for a few hours with none of the warnings.
> Maybe it has to do with the number of mails in the mailbox?
Clever thought, but while some of the users receiving the warnings have 30k
messages, others have only a few hundred.
> msgs=1 delete=10 expunge=10
Five hours running, no warnings. Any other thoughts?
> What kind of a test are you doing that causes these warnings?
A stress test which manipulates messages via IMAP fetch, copy, search, append,
store flags, expunge, etc. and also sends mail via SMTP. I'll try to narrow
down if there's a specific command which triggers it, or if dovecot-lda does
> Well, saving a copy of dovecot-uidlist file would be useful in such situation.
I added your patch to preserve dovecot-uidlist when reporting duplicate uids.
Here are two examples with uidlist files attached.
Mar 14 17:59:39 server dovecot[6698]: imap(pid 80181 user user272): Warning:
/Volume
> imaptest logout=0 copybox=foo delete=10 expunge=10 clients=2
> imaptest logout=0 copybox=INBOX box=foo delete=10 expunge=10 clients=2
>
> Does that fail with you either?
Ran both commands simultaneously for hours. No duplicate uid warnings.
While trying to use imaptest (-20100922, from
http://dovecot.org/nightly/imaptest/imaptest-latest.tar.gz) with the included
tests directory, it assert-crashes after a suspicious connect() failure:
$ ./imaptest user=foo pass=bar host=localhost test=tests
Error: connect() failed: No route to host
>> $ ./imaptest user=foo pass=bar host=localhost test=tests
>> Error: connect() failed: No route to host
>
> I can't reproduce this connect() failure. Not in OSX or Linux.
It has something to do with IPv6 or multiple aliases of localhost, for if I
comment out this line in client_new() like so it
Compiling dovecot-2.0.13 on OS X emits these warnings:
user-directory.c: In function user_directory_add:
user-directory.c:79: warning: comparison between signed and unsigned
user-directory.c:84: warning: comparison between signed and unsigned
Casting the left hand sides of the comparisons to time
> The file src/plugins/urlauth/urlauth-keys.c uses open(2) with O_EXLOCK, which
> to my knowledge is BSD specific.
Thanks for catching that. I guess that code should change to open the file
first and then lock it.
Using dovecot-2.1.15 if I run indexer-worker as a non-root user it fails with
an error:
Feb 11 13:06:47 indexer-worker: Error: user foobar: Error reading
configuration: net_connect_unix(/var/run/dovecot/config) failed: Permission
denied
This is what I added to 10-master.conf:
service indexer-wo
Any hints about the issue I wrote about on Feb. 11?
http://markmail.org/message/6g7itsu2u3fdnfkd
Thanks.
FTS indexing of binary attachments is broken in dovecot-2.1.15: the binary
data which fts_build_mail_real() sends to fts_build_body_block() (which sends
it to fts_backend_update_build_more()) is garbled. This patch ungarbles it but
I’m not positive it’s the best fix.
--- dovecot-2.1.15/src/pl
> http://hg.dovecot.org/dovecot-2.1/rev/6d45b9bd1cff fixes it
Yes it does. Thanks.
> Applied basically the same logic:
> http://hg.dovecot.org/dovecot-2.1/rev/b0e68c53771e
Cool, thanks.
> I guess you're building a new fts backend?
Just maintaining the one I already have.
FTS-searching through a virtual mailbox crashes dovecot-2.1.15 when the FTS
backend does not support lookup_multi.
src/plugins/fts/fts-api.h says for fts_backend_lookup() that "The arrays in
result must be initialized by caller." FTS backends can therefore assume that
the arrays are initialize
> wouldn't it be nice to have RFC 4468
Actually, Apple contributed such support a few hours ago but it's stuck in the
mailing list queue because the patch is big. As soon as Timo approves the
posting
> With v2.0 it's possible to do:
>
> disable_plaintext_auth = yes
> remote submit.domain.org {
> disable_plaintext_auth = no
> }
>
> I think that takes care of the need for X-PLAIN-SUBMIT?
Wouldn't that allow anyone from submit.domain.org to use plaintext, rather than
only submit users? I kno
> the MUA submits the message to the IMAP server and then the IMAP server
> forwards it to the MTA.
The MUA submits the message to the IMAP server. Then the MUA tells the
submission server to fetch the message from the IMAP server. The IMAP server
does not push the message out to the MTA.
> Yes, it allows submit.domain.org to use plaintext for all authentications.
> But typically your submit server wouldn't be trying to authenticate as
> anything else as the submit user, I think?
> In v1.2 you could also do something similar to this by adding the submit
> server's IP to login_tr
> That says the submit server's IMAP client must support STARTTLS+SASL
> PLAIN authentication.
Yes.
> Which is exactly the opposite of what X-PLAIN-SUBMIT does.
X-PLAIN-SUBMIT is intended to allow a submission server to connect to the IMAP
server, send STARTTLS, and then authenticate using a pl
> except if auth { mechanisms } doesn't have PLAIN
Precisely. Hence, X-PLAIN-SUBMIT.
Dovecot's transactions often write-lock dovecot.index.log twice (without
unlocking in between), and then unlock it twice. Is that intended, or is that
a bug? If I read the man pages correctly, double write-locking is pointless
but safe. But double unlocking could cause data corruption during
Here is a patch to fix the problem where an imap process runs away when
imap-zlib is in use. The backtrace showed:
io_loop_handler_run ->
stream_send_io ->
client_output ->
o_stream_flush ->
o_stream_zlib_flush ->
o_stream_zlib_send_flush
When o_stream_zlib_flush returns 0, stream_send_io reins
> Is there a tool equivalent to the system "passwd" command
The dovecotpw command may be a good place to start.
> 1272011889.M384349P30156.f12barry.office.onelan.co.uk,S=6494,W=6606:2,S
The size of this file should be 6494 bytes (S=6494) but in your attachment it
is 6519 bytes. Did something insert a header into the file after dovecot
received it? Perhaps this one, which (with a CR added) is 25 bytes, t
> To recover from this error I think I need to:
>
> 1. service dovecot stop
> 2. rename all the mail files to have the S= match the size of the file on
> disk
> 3. remove all the dovecot.* files
> 4. service dovecot start
>
> Is this correct?
I believe so but I'm not an authority on this p
> May 3 15:47:37 host dovecot: [ID 583609 mail.error] IMAP(user):
> close(/home/user/Mail/R-Help.lock) failed: Disc quota exceeded
> May 3 15:47:37 host dovecot: [ID 583609 mail.error] IMAP(user): Raw
> backtrace: 0xb0e58 -> 0xb0894 -> 0x552b4 -> 0x55508 -> 0x55774 -> 0x55d9c ->
> 0x5759c -> 0
> I am a bit new to this kind of debugging.
> What happens if I turn on core dumps on Solaris?
See the "Core Dumps" section of http://www.dovecot.org/bugreport.html.
> Does this fix help against this sort of crashes?
> http://hg.dovecot.org/dovecot-2.0/rev/8f251e0bc02d
Probably not. You're run
Running 2.0.beta5 on Mac OS X with HFS+J, I often see this error in the log:
Fri May 14 12:25:59 gromit dovecot[5466]: imap(pid 8101 user joe): Error: mdbox
/var/spool/imap/dovecot/mail/mailboxes/INBOX/Foobar/dbox-Mails: map uidvalidity
mismatch (1273852899 vs 1273853949)
Fri May 14 12:25:59 gro
On Apr 14, 2010, at 9:25 PM, Mike Abbott wrote:
> Dovecot's transactions often write-lock dovecot.index.log twice (without
> unlocking in between), and then unlock it twice. Is that intended, or is
> that a bug?
Turns out it was a misunderstanding. No such double locking occ
> altair/phil /home/phil 162> telnet 172.30.0.24 143
> Trying 172.30.0.24...
> Connected to 172.30.0.24.
> Escape character is '^]'.
> * OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND
> UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS
> LIST-EXTENDED I18NLEVEL=
> Anyway, with the tag it does work on IMAP. But it still fails on POP
For POP3 the command is STLS.
> Well, that kinda complicates a "STARTTLS tunnel"
Perhaps you might be interested in these commands. I'm not sure about their
portability but they work tolerably well in scripts on Mac OS X 10.6.
$ openssl s_client -connect yourhost:imap -starttls imap
$ openssl s_client -connect yourhost:pop3
> So storage's uidvalidity had changed 17,5 minutes after Foobar's index
> was created. Was this a real user?
No, this was a test user running a simulation. I can reproduce it at will if
you need any more information.
> Since both dates are May 14th and
> your mail was also dated May 14h, was t
>> Nah, forget it. Looks like the uidvalidity assignment is done in a
>> stupid racy way.
>
> http://hg.dovecot.org/dovecot-2.0/rev/7fc5db26f6eb should help?
Yes, that helps. Thank you.
When my dovecot-2.0.beta5 auth module logs a 552-byte debug message, the
message is split into two lines and also a null error message:
Wed Jun 9 23:44:29 gromit dovecot[58892]: auth: Error:
I think this has to do with the use of PIPE_BUF (512) sized buffers in the
logging code, and the !line_
1 - 100 of 176 matches
Mail list logo
