In traversing this thread I see a few different issues being reported. In no
particular order I see:
[Nicholas Riley]
> iOS Mail still opens lots of simultaneous IMAP connections, eventually
> complains about not being able to contact the server, and doesn't seem to do
> anything that uses Dov
> Do you think [moving IMAP IDLE connections to a separate imap-idle process]
> would work for you also?
Probably. It always depends on the details. Forking a new imap process every
time there's a little input to read or output to send might perform poorly
under load. Having a pool of ready
> how [FTS indexing] could be improved for everyone in future
For sites which set client_limit > 1 it would help performance not to stall for
INDEXER_WAIT_MSECS when polling the indexer for input. Currently dovecot
unwinds back out to the main command loop repeatedly to allow other clients to
> (You don't you have any thoughts only getting replication to ignore the
> “submit” user, do you?)
Just remove it from your config and disable urlauth. That will also fix the
security hole you opened when you sent your submit user's password to the list
:).
> default_fields = home=/Library/Server/Mail/Data/mail/%u
Try:
default_fields = home=/Library/Server/Mail/Data/mail/users/%u
In 2.2.5 and earlier it appears that mailbox_keywords_unref(&keywords) is not
called in some return paths from cmd_append_handle_args(). Should it be?
> x append inbox catenate (url ;invalid; url {5}
>
> Dovecot replies with "+ OK" because it wants to read all the URLs into memory
> before parsing them, while catenate.pl expects an error message immediately.
I see that Example 4 in Appendix A of RFC 4469 explicitly allows both models.
Here's
> Do you think you might re-submit the matching BURL support to Postfix?
I don't think re-submitting is a good idea unless Wietse & co. request it,
which I doubt will happen.
Attached please find a perl script which tests the CATENATE support in dovecot.
I used this to test my CATENATE implementation a few years ago and it runs
fine against dovecot in OS X Server. When run against dovecot-2.2.4 though it
always fails or hangs, which in some cases means we interpret
> I fixed the most obvious places in hg
Thanks. Unfortunately CATENATE still fails for me in various ways. I'm trying
to isolate test cases.
> Both of these are fixed in hg.
Confirmed. Thanks. I have no more major issues with URLAUTH at this time.
>> without having set *mpurl_r to NULL
>
> Right, fixed: http://hg.dovecot.org/dovecot-2.2/rev/24aa10efe132
That fixes it, thanks, but I wonder if it's incomplete? I notice that these
also sometimes don't set *mpurl_r:
imap_msgpart_url_create()
imap_msgpart_url_parse()
imap_urlauth_fetch()
Tha
>> CATENATE with no message parts works but, IMO, shouldn't:
>>
> Changed: http://hg.dovecot.org/dovecot-2.2/rev/5e2fa592c268
Confirmed. Thanks.
Dovecot-2.2.1 does not appear to support URLs specified via
non-synchronizing literals
>
> http://hg.dovecot.org/dovecot-2.2/rev/8e5ff6809d75 should fix this
Looks better, thanks.
Dovecot-2.2.1 plus Timo's recent CATENATE and URLAUTH fixes mishandles literals
after bad URLs. (As before remember that the "foobar" text below is really
"foobarCRLF" hence the length of 8. Also, last time some MTA discarded an
important single leading space character in the snippet I quoted
Testing URLAUTH in dovecot-2.2.1 plus Timo's recent CATENATE and URLAUTH fixes
eventually trips some assertions. No simple sequence of commands always hits
these; they appear to be timing-dependent.
The first one is:
May 02 17:47:17 imap(pid 50490 user submit): Panic: file imap-client.c: line
It's the inconsistency that bothers me. Plain old APPEND doesn't allow empty
messages but CATENATE does?
Dovecot-2.2.1's imap processes crash reliably when they use an IMAP URL with an
invalid access specifier. A backtrace and some debug output follows. The
crash is likely caused by imap_urlauth_fetch_parsed() returning 0 without
having set *mpurl_r to NULL, and then imap_urlauth_fetch_local() fr
In dovecot-2.2.1 neither the SELECT nor the EXAMINE commands include an
untagged URLMECH reply. (Note, this is not the one mandated by the RESETKEY
command.)
AFAICT RFC 4467 does not require an URLMECH reply to SELECT or EXAMINE but
without it clients have no way of knowing about authorization
> Dovecot-2.2.1 does not appear to support URLs specified via non-synchronizing
> literals
Or synchronizing literals either:
b2 append inbox catenate (url {8}
b2 BAD Error in IMAP command APPEND: Invalid arguments.
Although the consequences of this are less severe since clients should send no
Something ate an important leading space from my message.
> b3 append inbox catenate (text {0+}
> text {8+}
> foobar
> )
> b3 OK [APPENDUID 1366726248 13] Append completed.
There was and should be a single space before the "text {8+}" above.
Dovecot-2.2.1 allows empty messages to be APPENDed when using CATENATE:
b1 append inbox catenate (text {0+}
)
b1 OK [APPENDUID 1366726248 12] Append completed.
Contrast this with regular APPEND:
b2 append inbox {0+}
b2 NO Can't save a zero byte message.
Note that zero-size literals are OK bu
Dovecot-2.2.1 does not appear to support URLs specified via non-synchronizing
literals (RFC 2088 LITERAL+), and also does not read and discard the literal+
input after reporting the error. This results in the literal+ input being
interpreted as IMAP commands, which could alter the user's mail s
I'm pleased to see that dovecot-2.2 includes support for RFCs 4467 and 4469
(URLAUTH and CATENATE). I have begun testing these features (in dovecot-2.2.1)
and comparing their functionality against Apple's implementation. So far I
have discovered a few inconsistencies. I will report each of th
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
> 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.
> http://hg.dovecot.org/dovecot-2.1/rev/6d45b9bd1cff fixes it
Yes it does. 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
Any hints about the issue I wrote about on Feb. 11?
http://markmail.org/message/6g7itsu2u3fdnfkd
Thanks.
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
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 */
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
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)?
--- 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
> 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.
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
>> $ ./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
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 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.
> 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
> 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
> 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?
> 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.
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
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
> 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
>> 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
> 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 +
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
> 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
> 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
Typo on line 292 of src/lib-master/master-login-auth.c in 2.0.8: tuah.
> 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.
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
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
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
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/
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
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) !=
> Wonder if attached patch fixes it.
Yes. Thanks!
> Oh, interesting.. What about if you run it with two users?
With two users that same assertion trips. One user runs fine.
> What about just:
>
> imaptest clients=10 user=user1 pass=test no_tracking logout=0 copybox=Copies
No crashes this way. It seems to need the different users.
> This is with v2.0.3 release, not hg?
Correct, 2.0.3 plus your asserts from this thread.
> --enable-devel-checks
Doh, that's what I
Seems related to maildir_copy_hardlink(). No crashes with
maildir_copy_with_hardlinks=no.
> I'll try to narrow it down further (nix the search, turn off quotas, etc.).
imaptest clients=60 user=user\%d pass=test no_tracking logout=25 copybox=Copies
does it too... (no search commands)
And it happens with zero mail_plugins everywhere.
But this does not trip that assertion:
imaptest clie
> imaptest logout=1 clients=4
> imaptest logout=1 user=tss2 box=shared/tss/INBOX clients=4
Yes, I can reproduce this assertion failure:
Panic: file maildir-save.c: line 79 (maildir_file_move): assertion failed:
(*mf->tmp_name != '\0')
with:
imaptest clients=60 user=user\%d pass=test no_tracking l
>> lda(pid 8212 user user3): Error: Opening INBOX failed: Mailbox doesn't
>> exist: INBOX
>> [...]
>> tag NO Mailbox doesn't exist: INBOX
>
> For newly created users that don't have the Maildir directory created
> yet?
No, for users who already have their Maildir.
> This is with Maildir++ quota
> So are you saying that this directory was actually created by Dovecot?
Yes. No migration, no Courier.
> Are these easy to reproduce?
Yes, on my system. I'll try imaptest.
> user1 is accessing user2's INBOX?
Not intentionally. User1 and user2 happen to be logged in at the same time and
w
Perhaps related to the other errors I just reported, I also see a few of these
in the dovecot-2.0.3 logs:
lda(pid 8212 user user3): Error: Opening INBOX failed: Mailbox doesn't exist:
INBOX
lda(pid 8212 user user3): msgid=<201009240906510365.1gj1fpfhrh...@mail>: save
failed to INBOX: Mailbox doe
Hm, I found more revealing errors after sending that message. These are
scrubbed a little differently, to show two user names:
imap(pid 5720 user user1): Error:
open(/path/to/mail/user2/tmp/1285336854.M157825P5720.my.mail.server) failed: No
such file or directory
imap(pid 5720 user user1): Err
Dovecot-2.0.3 reported:
Error: Maildir: Found unwanted directory /path/to/mail/user/cur/:2,FST, but
rmdir() failed: Directory not empty
and sure enough, this directory really does exist and contain a valid message
file:
# cd /path/to/mail/user/cur/
# ls -lR
total 384
drwx-- 8 vmail vmai
How can a dovecot-2 plugin safely use file-locks or file-dotlocks when the
processes into which it plugs handle multiple connections? (Via, e.g.,
service imap {
client_limit = N
service_count = 0
})
Dovecot's file-locks and file-dotlocks do not appear to support
nesting/recursion.
For insta
When might deduplication of attachments work with maildir?
Sometimes dovecot-2.0 sends this untagged response to clients:
* OK Indexed -2147483648% of the mailbox, ETA 0:00
I imagine there's a bug in there somewhere.
There is a roff typo in pigeonhole's sievec.1.in. Roff treats the leading
apostrophe on line 54 as an invalid command and produces bad output:
dump to be written to stdout. The out-file argument may
also be omitted, which has the same effect as for a com-
> 1. What hash algorithm to use?
> 2. Should I add support for trusting hash uniqueness
Use two hash functions and concatenate the hashes. While both hash systems may
eventually be hacked it is unlikely that hacking them will result in a targeted
alias.
> attachments/ha/sh/hash-guid, which is a hard link to:
> attachments/ha/sh/hashes/hash
If I store, say, all students' mail directories on one file system, and all
teachers' mail on another, will your SIS store one copy of each attachment, or
one copy per file system?
> That being the case I'd avoid the word "virtual". It seems we also want to
> avoid the word "home".
+1. "Virtual" implies it's only for virtual users. "Home" means $HOME.
> So I see logic in calling it the "user state directory" which could be
> "userdir" for short.
"Userdir" may still imp
> Current implementation checks how many hard links are left for the hash
I haven't followed all the details and speculation, but this talk of
hard-linking makes me wonder how SIS will work with mail stores spread across
multiple file systems.
The quota plugin in 2.0.beta6 leaks 2KB "quota settings" pools. Here is a
patch to plug this leak, assuming you intended the caller of quota_init to
retain ownership of the quota_set. If on the other hand you intended for
quota_init to assume ownership of the quota_set, then the quota_settings
>> Dovecot-2.0.beta6 sometimes terminates client connections and reports these
>> errors:
>> Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
>> offset=6216579): msg header has bad magic value
>> Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
>> offset=6216579):
> I couldn't find anything obviously wrong in the code.
Figured it out. The t_pop in client_handle_input was clobbering
imap_clients->command_queue->name. This is because cmd_uid allocated the name
from the wrong pool. Here is a patch to fix it. Forget my other patch (to
imap_refresh_procti
> Is it complete garbage or 0xde character? (Or if you don't use
> --with-devel-checks then 0xde shouldn't be appearing.)
It is often 0xde with devel-checks on.
>> 6 imap0x000105867333
>> imap_refresh_proctitle + 218 ->
>> 7 imap0x0001058666ce cmd_sync_continue
>> + 199 ->
>
> But how does this happen? Did it optimize away some functions
Yeah optimized out tail-calls, e.g. clie
The "imap" process of dovecot-2.0.beta[5,6] grows very large (I impose no
system limits), e.g. exceeding 4.8GB on a 64-bit system. These messages appear
in the logs:
Warning: Growing pool 'imap client' with: 2048
Warning: Growing pool 'Cache fields' with: 2048
Warning: Growing data stack with: 3
Dovecot-2.0.beta6 sometimes terminates client connections and reports these
errors:
Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
offset=6216579): msg header has bad magic value
Error: Corrupted dbox file /Volumes/Mail/joe/storage/m.1 (around
offset=6216579): uid=0 points to b
>> Panic: file mailbox-list.c: line 318 (mailbox_list_get_unexpanded_path):
>> assertion failed: (*location == '0')
>
> Fixed: http://hg.dovecot.org/dovecot-2.0/rev/6e1247609440
Yes. Thanks.
2.0.beta6 assert-fails for me when:
- using mdbox (maildir is OK)
- my authentication module returns the mail= and mail_location= attributes
(relying on mail_location from 10-mail.conf is OK)
- a user logs in for the first time and selects his nonexistent INBOX
The error is:
Panic: file mailbox-l
> Related to PIPE_BUF, yes, but problem was in the sending part. Fixed:
> http://hg.dovecot.org/dovecot-2.0/rev/5ede18fe35fa
Yes, that fixes it. Thanks.
> Is OSX's PIPE_BUF really only 512 bytes
Yes.
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_
>> 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.
> 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
> 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
> Anyway, with the tag it does work on IMAP. But it still fails on POP
For POP3 the command is STLS.
> 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=
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
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
> 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
> 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
> 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
> 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
1 - 100 of 176 matches
Mail list logo
