[Dovecot] Simulating UW Snarf...

[Todd Piket]

The perfect scenario would be if Dovecot could check /var/mail/%u to see 
if there is new mail and if so, *attempt* to move it to ~/Maildir.  If 
Dovecot gets an over quota message it can stop and just return "No new 
mail" to the client and allow the user to see existing mail, but do 
nothing more.  This should happen every time the user "checks" for new 
mail such that an under quota scenario (user deletes Sent folder 
messages, for instance) results in mail from /var/mail/%u to be 
"delivered" to ~/Maildir.

This is bascially what UW-IMAP does.  It is quite handy in our 
situation.  The problem with doing this with Dovecot and/or Maildir is, 
I believe, you must introduce some kind of locking mechanism in 
/var/mail/%u because the delivery agent and Dovecot may step on each 
other's toes otherwise.  Since locking is "bad" in maildir this is not 
ideal.

Regards,

  ------------------------------------------------------------
| Todd Piket                        | Email: todd at mtu.edu    |
| Programmer/Analyst                | Phone: (906) 487-1720  |
| Distributed Computing Services    |                        |
| Michigan Technological University |                        |
  ------------------------------------------------------------


Lorens wrote:
> On Wed, Feb 08, 2006 at 03:50:17PM -0500, Todd Piket wrote:
>> Thank you Timo and Lorens for your quick responses.  Timo, I thought as 
>> much in regards to the rename()s, but I was hoping.
>>
>> Lorens, the INBOX in /var/spool/mail/%u would keep the INBOX on a 
>> non-quota file system.  This means Dovecot reads the user's INBOX from 
>> /var/spool/mail/%u which is not what we want.  We want the INBOX to be 
>> in the home directory.  Users could leave mail in /var/spool/mail/%u and 
>> it would never go over quota.  That is, obviously, not what we want.
> 
> OK... quick check, yes, in a pure maildir environment even when
> I keep my mails "new", they are still moved from new to cur. I
> wasn't certain :-)
> 
>> We 
>> need to never bounce mail yet deliver the mail that has built up for an 
>> over quota user as quickly as we can once that user goes below quota. 
>> If Dovecot moved the mail from /var/spool/mail/%u to the user's homedir 
>> then that is exactly what I want.  As long as it fails gracefully if the 
>> user is over quota.
> 
> I suppose that your "perfect" scenario would be if dovecot moved
> mail from /var/spool/mail/%u to ~/Maildir before sending it to
> the client, and failed with an "over quota" error message if the
> move to the maildir failed because it was over quota? Of course
> that means that mail is only moved when the client reads it, not
> as soon as he goes under quota, but you have the same behaviour
> with the other solutions.