[Dovecot] Simulating UW Snarf...

[Todd Piket]

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.  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.

Other reasons keep us from creating separate mail queues and attempting 
to redeliver at intervals.  Mainly, volume of mail.

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 02:18:06PM -0500, Todd Piket wrote:
>> I already wrote to Timo, but I thought some others on this list may have 
>> had a similar situation.  So here goes:
>>
>> The scenario at Michigan Technological University stems from long 
>> standing traditions and policies that probably won't change.  That said, 
>> two of the policies are 1.)we don't bounce mail and 2.)we guarantee 
>> delivery when we accept a piece of mail.  The UW IMAP "snarf" capability 
>> was nice because it allowed us to introduce file system, per user quotas 
>> w/o worrying about the "INBOX" in an over quota situation.  This is 
>> because the user could still read mail.  The delivered mail would get 
>> "snarfed" from /var/mail/user when the user went back under quota.
>>
>> In our test cases with switching to Maildir with Dovecot, we deliver 
>> directly to the user's INBOX instead of /var/mail/user so what do we do 
>> when the user is over quota because we can't bounce the mail?
> 
> Why do you do this?  What would be the problem with something
> like
> 
>     default_mail_env = maildir:~/Maildir:INBOX=/var/spool/mail/%u
> 
> which if I've understood correctly means that the user's stored
> mail is in his home directory Maildir, while new mail is
> delivered into /var/spool/mail/%u.
> 
> I've never had reason to try this, but these are obviously on 
> different filesystems, and it seems to me as if it would be
> functionally equivalent to having Maildir/new on a different
> file system.
> 
>> After many lengthy discussions our thought was this.  Could we 
>> symbolically link the user's "Maildir/new" to a non-quota file system 
>> such that the move from "new" to "cur" would fail if the user is over 
>> quota?
> 
> See Timo's response.
> 
> In a more general way, how do you deal with people keeping all
> their mail in the INBOX? Is it only that it's annoying to have
> your mail marked "new"?
> 
> HTH.