headers
Obantec Support | 24 Mar 15:30

quota issue POP3

Hi

Just u/g to RH FC3 from RH8.0 which seemed to work fine with quotas.

I have quotas for usernames set up as

/home/domain/domainX/username/ for web space 50MB say 48MB used so 2MB free
and
/var/mail/spool/username for email.    100MB (60MB used so 40MB is
available). /var/mail/username is symbolic linked via to spool/mail under
/var

dovecot seems to be using the quota for /home/.. and sees only 2MB so
refuses to write file back.

maillog is reporting (username and IP replaced).

Mar 16 13:20:03 proteus2a pop3-login: Login: username [11.22.33.44]
Mar 16 13:20:03 proteus2a pop3(username): Error rewriting mbox file
/var/mail/username: Disk quota exceeded
Mar 16 13:20:03 proteus2a pop3(username): write() failed with mbox file
/var/mail/username: Disk quota exceeded

i am assuming this is when pop3 login is trying to re-write file back when
deleting emails.

Mark
--
Obantec Support
www.obantec.net
(Continue reading)

Permalink | Reply | 3 comments |
headers
Aaron VanDevender | 24 Mar 21:57

Re: automatic flag updates


Timo,

(Sorry for the delay in replying. I had a...thing.)

On Wed, 2004-12-01 at 00:54 +0200, Timo Sirainen wrote:
> On 1.12.2004, at 00:30, Aaron VanDevender wrote:
> 
> > On Tue, 2004-11-30 at 09:00 +0200, Timo Sirainen wrote:
> >>> at this point I expect client A to change the status of the mail in
> >>> question to SEEN, but it stays as UNSEEN. The session below is from
> >>> client A. Command A00069 reports [UNSEEN 16265]
> >>
> >> That does seem to be bug.
> >
> > Do you mean an Evolution bug, or a Dovecot bug?
> 
> Dovecot bug.

Is this a dovecot bug that might be getting a fix anytime soon?

> > This race window is even wider for other folders. If the client spends
> > most of its time in INBOX, and only periodically SELECTs over to, say, 
> > a
> > Mailing-List folder, for a STATUS or a LIST check, then most likely if 
> > a
> > message in the Mailing-List folder is marked SEEN it won't be picked up
> > by the client at all, because it was NOOPing INBOX and SELECT doesn't
> > return FETCH FLAGS. The only way to avoid this is just to have SELECT
> > return FETCH FLAGS updates.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timo Sirainen | 24 Mar 22:38
Picon
Picon
Favicon

Re: automatic flag updates

On Thu, 2005-03-24 at 14:57 -0600, Aaron VanDevender wrote:
> > >>> at this point I expect client A to change the status of the mail in
> > >>> question to SEEN, but it stays as UNSEEN. The session below is from
> > >>> client A. Command A00069 reports [UNSEEN 16265]
> > >>
> > >> That does seem to be bug.
> > >
> > > Do you mean an Evolution bug, or a Dovecot bug?
> > 
> > Dovecot bug.
> 
> Is this a dovecot bug that might be getting a fix anytime soon?

It should be fixed in 1.0-tests/stable. Most likely won't get fixed in
0.99.x..

> > > This race window is even wider for other folders. If the client spends
> > > most of its time in INBOX, and only periodically SELECTs over to, say, 
> > > a
> > > Mailing-List folder, for a STATUS or a LIST check, then most likely if 
> > > a
> > > message in the Mailing-List folder is marked SEEN it won't be picked up
> > > by the client at all, because it was NOOPing INBOX and SELECT doesn't
> > > return FETCH FLAGS. The only way to avoid this is just to have SELECT
> > > return FETCH FLAGS updates.
> > 
> > In theory that could work for a single session, but I don't think it's 
> > such a good idea. It assumes that all clients want to know about all 
> > changes all the time. This isn't true for example for Pine, 
> > webmail+caching imap proxy, and other clients that just don't care and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timo Sirainen | 24 Mar 22:44
Picon
Picon
Favicon

Re: Pine and prefix - LIST command bug?

On Mon, 2005-03-21 at 13:11 +0000, Chris Wakelin wrote:
> On Mon, 21 Mar 2005 14:38:19 +0200 Timo Sirainen <tss <at> iki.fi> wrote:
> 
> > On 21.3.2005, at 14:09, Chris Wakelin wrote:
> > 
> > > Having said that, Pine is still getting confused. This time it's trying
> > > 'LIST "" ~/mail' and getting no results whereas UW-IMAP gives '* LIST
> > > (\NoSelect) "/" ~/mail'.
> > 
> > How about if LIST "~/mail/" "" returned ~/mail/ even if the namespace 
> > is hidden?
> 
> If we're imitating UW-IMAP then LIST "~/mail/" "" should return "~/".

Yes, but I was thinking we could do it a bit more easily by changing the
behavior to be different from UW-IMAP, as long as Pine worked with it. I
don't think the reply above would necessarily be against IMAP spec,
because it would be correct for visible namespaces.

> I guess the second Pine problem is that it tries to make sure the 
> "~/mail/" prefix exists and tries to create it if it doesn't. I'm not 
> sure whether it has a right to expect this to work.

It does if the first reply returned ~/. That's why I wanted it to make
return ~/mail directly so I wouldn't have to create LIST matching for
namespace prefixes too :)

Did you try if the patch in previous mail happened to work? If not, I
guess I'll have to add that prefix-LISTing code..
(Continue reading)

Permalink | Reply | 3 comments |
headers
Timo Sirainen | 24 Mar 22:47
Picon
Picon
Favicon

Re: dovecot-ldap with tls

On Mon, 2005-03-21 at 11:59 +0800, ck wrote:
> Can somebody help me to find out how to use dovecot to connect to my
> ldap server which has the tls support?
> Currently I'm using my dovecot to connect to ldap without tls and soon
> my ldap server will apply the tls and all others server have to connect
> through the tls.

Sorry, Dovecot's LDAP code doesn't support TLS yet, and I won't be
writing it myself anytime soon.
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 24 Mar 22:50
Picon
Picon
Favicon

Re: Troubleshooting help

On Sun, 2005-03-20 at 15:03 -0500, Paul Michael Reilly wrote:
> Somehow, hopefully to be determined, I got my Thunderbird/dovecot
> Fedora Core 3 configuration into a real snit, such that I can no
> longer access my INBOX.
> 
> When Thunderbird tries to get the INBOX content (or get new mail) it
> reports "The current command did not succeed.  The mail server
> responded: Invalid messageset: -2147483648:*."  Scouring logs and
> googling has come up empty.  Now I'm flailing at trying to get to a
> state that this problem does not exist.  I'd like to understand how
> this situation arose and how to deal with it better if it happens to
> any other users on my mail server.

mbox or maildir? Probably mbox? Sounds like you received an email with a
very high X-UID header which broke things. Probably easiest way to fix
it would be to delete Dovecot's index files (.imap.index*) and remove
all X-UID headers from your INBOX file:

grep -v '^X-UID: ' inbox > inbox2

Dovecot 0.99.14 version doesn't allow this to happen anymore. I guess
you were using older version?
Permalink | Reply | 2 comments |
headers
Timo Sirainen | 24 Mar 22:55
Picon
Picon
Favicon

Re: Fw: Auto Create Folders

On Mon, 2005-03-21 at 13:31 -0500, Chris L. Franklin wrote:
>  PS. In the end all's it comes down to is i was wounder if there was a way 
> to
>  have dovecot auto create a folder or a list of folders at login. 

I can't really think of how I would implement this in any generic way. I
can only think of ugly kludgy solutions. 

There is a pretty simple way to do it though: create a script/binary
which checks HOME/MAIL environment itself and creates the folders, then
executes Dovecot's imap binary. Then set mail_executable in config file
to your wrapper.

> OR really
>  if there was a way to tell dovecot a list of folders a user COULD NOT 
> delete
>  (But could delete the folders in side).

That could be done with ACLs, once Dovecot supports them.
Permalink | Reply | 501 comments |
headers
Timo Sirainen | 24 Mar 23:16
Picon
Picon
Favicon

Re: Segfault in imap process

On Tue, 2005-03-22 at 19:12 -0500, Todd Burroughs wrote:
> It's using mbox over NFS and I've configured "mmap_disable = yes".
> 
> The mailbox that it crashed on is one of our support mailboxes and it
> is pretty busy.  In the last 1/2 hour, it received over 100 emails.
> 
> I had a look at the code, but didn't notice anything obvious.  Thanks
> for any help...
> 
> 
> Here's the log messages:
> dovecot: Mar 22 18:22:23 Error:  19697 IMAP(support): UIDVALIDITY changed (1111532787 -> 1111533642)
in mbox file /mailhome/new/s/support/mbox

This is your primary problem. Why is it changing? It sounds like
Dovecot's index files aren't in NFS, and you're accessing the mbox from
multiple computers with different index files?

That alone doesn't break it, but if the first message is expunged with
non-Dovecot/c-client software, the UIDVALIDITY is lost and Dovecot
creates a new one. But another Dovecot instance with existing index
files tries to use the old UIDVALIDITY and so it complains about the
change.

Is something else than Dovecot expunging the messages, or
deleting/truncating the mbox entirely?

> #0  0x08079f14 in mail_cache_sync_lost_handler (index=0x0)
>      at mail-cache-sync-update.c:152
> 152             file_cache_invalidate(index->cache->file_cache, 0, (uoff_t)-1);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timo Sirainen | 24 Mar 23:21
Picon
Picon
Favicon

Re: quota issue POP3

On Thu, 2005-03-24 at 14:30 +0000, Obantec Support wrote:
> Mar 16 13:20:03 proteus2a pop3-login: Login: username [11.22.33.44]
> Mar 16 13:20:03 proteus2a pop3(username): Error rewriting mbox file
> /var/mail/username: Disk quota exceeded
> Mar 16 13:20:03 proteus2a pop3(username): write() failed with mbox file
> /var/mail/username: Disk quota exceeded
> 
> i am assuming this is when pop3 login is trying to re-write file back when
> deleting emails.

Right. Dovecot 0.99.x works very badly with filesystem quota. 1.0-stable
versions would be slightly better, but probably will still fail if quota
is completely reached. It's in my TODO to fix this before v1.0.
Permalink | Reply | 1 comment |
headers
Timo Sirainen | 24 Mar 23:30
Picon
Picon
Favicon

Re: Address with whitespace shows as ""@MISSING_DOMAIN

On Tue, 2005-03-22 at 10:49 +0000, Chris Wakelin wrote:
> It seems that Dovecot gets confused when presented with a header like:
> 
> From:    someone <at> somewhere.org
> 
> i.e. with leading whitespace and no "friendly name"
> This shows up as ""@MISSING_DOMAIN in clients, such as Pine, that 
> believe what Dovecot tells them rather than parsing the headers 
> themselves (e.g. Thunderbird).

Whops. I was skipping spaces everywhere else except at the beginning.

Fixed in CVS for 1.0-test/stable. Or use this patch:

Index: src/lib-mail/message-address.c
===================================================================
RCS file: /var/lib/cvs/dovecot/src/lib-mail/message-address.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- src/lib-mail/message-address.c	14 Mar 2005 19:08:59 -0000	1.11
+++ src/lib-mail/message-address.c	24 Mar 2005 22:27:38 -0000	1.12
@@ -277,6 +277,8 @@
 	ctx.pool = pool;
 	ctx.str = t_str_new(128);

+	rfc822_skip_lwsp(&ctx.parser);
+
 	(void)parse_address_list(&ctx, max_addresses);
 	if (!pool->datastack_pool)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane