[imp] user quotas and imap behaviour

[Oscar Renalias]

Joseph Brennan escribió:
> =

> > Conversation with a "quota exceeded" user:
> > 1 login anotheruser anotherpasswd
> > 1 OK LOGIN completed
> > 2 select inbox
> > * 30 EXISTS
> > 2 NO SELECT failed: New mail move failed: Disc quota exceeded
> > 3 status inbox (unseen)
> > * STATUS inbox (UNSEEN 3)
> > 3 OK STATUS completed       <<--- this works
> > 4 fetch 1 all
> > 4 BAD Command unrecognized: FETCH    <<--- but this doesn't
> > (if FETCH doesn't work, I'm afraid we can't do anything else...)
> =

> We have user quotas, and use U Wash imap2000, and get different results=
.
> Imapd complains about not being able to write the lock file, because th=
e
> user in this test below is way over quota, but weirdly (?) it appends
> the new mail to mbox anyway:

How can it append to mbox if there isn't enough space??? What happened
to the message in the mail spool? Were they still there? Or had they
surpringly vanished?
And, are you using a mail spool and then mbox in the user's home
directory, or does your MTA deliver the mail directly to the user's
mbox? Because it seems that in your case the imap server doesn't
complain about not being able to move the mail, but about not being able
to create the lock file to prevent concurrent access to the mbox file.

Thank you for your patience ;-)
 
> * OK mailhub1.cc.columbia.edu IMAP4rev1 2000.281 at Wed, 29 Nov 2000
> 10:01:07 -0500 (EST)
> a1 login jb51 pass
> a1 OK LOGIN completed
> b2 select inbox
> * NO Mailbox vulnerable - error creating /c/u/1/j/jb51/mbox.lock: Disc
> quota exceeded
> * 144 EXISTS
> * NO Mailbox vulnerable - error creating /c/u/1/j/jb51/mbox.lock: Disc
> quota exceeded
> * 145 EXISTS
> * NO Mailbox vulnerable - error creating /c/u/1/j/jb51/mbox.lock: Disc
> quota exceeded
> * 1 RECENT
> * OK [UIDVALIDITY 965938213] UID validity status
> * OK [UIDNEXT 176] Predicted next UID
> * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
> * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)]
> Permanent flags
> * OK [UNSEEN 81] first unseen message in /c/u/1/j/jb51/mbox
> b2 OK [READ-WRITE] SELECT completed
> c3 fetch 1 all
> ... gets message ...
> =

> I did this test with a message in spool, and that message was appended
> to
> mbox and was available for fetch.
> =

> Maybe a client should catch the NO messages and stop, but then again th=
e
> final result of the command is "b2 OK..." so I don't think the client
> can
> be faulted for continuing.
> =

> Joseph Brennan                           postmaster@columbia.edu
> Academic Technologies Group, Academic Information Systems (AcIS)
> =

> --
> IMP mailing list: http://horde.org/imp/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe@lists.horde.org

--
Oscar Renalias / oscare@fib.upc.es / FIB / UPC
House music is a state of mind