[Dovecot] Simulating UW Snarf...

[Todd Piket]

Geo,

A scenario similar to what you describe has been discussed in the group 
and is still a possibility.  The plugin for Dovecot is presenting itself 
as the simplest and cleanest solution so far.  The MTA will, of course, 
"do the right thing" when it detects the user is over quota.  Our 
opinion is it will be simpler to deliver the mail to a non-quota file 
system in the over quota case, most likely /nonquotafs/%u/Maildir.  The 
plugin would simply check to see if there is mail for the user in this 
area upon FETCH and/or EXPUNGE and, if so, move it to the user's quota 
enabled homedir if the user is no longer over quota.

This means there will never be a situation where something is hopelessly 
trying to deliver email to a user who never checks it (this does happen 
here).  That is just a waste of processing time, IMHO.  This way it just 
sits there taking up space until the user goes under quota or our 60-day 
old mail cleaner removes it.

Again, IMO, having Dovecot handle the check is the more elegant solution.

Regards,

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


Geo Carncross wrote:
> On Wed, 2006-02-08 at 22:18 +0100, Lorens wrote:
>>> 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.
> 
> This sounds like an Extremely Complicated[tm] solution is desired where
> one doesn't appear to be necessary, just a bunch of little steps:
> 
> 1. Have your MTA deliver messages into $HOME/Maildir
> 
> Your MTA should tempfail if delivery fails because write() failed [which
> it would if the user went over quota]. Temporary failures should be
> retried later.
> 
> 2. If you really want to "never bounce [local] messages", consider
> configuring your MTA to simply never expire local mail- although some
> users consider bounces useful as it means the recipient didn't receive
> the mail in a [reasonable] amount of time.
> 
> In any event, on qmail this is trivial:
> 
> (cd /var/qmail/queue/local && find . -type f) \
> | awk '{ print "touch -c /var/qmail/queue/info/"$0 }' | sh
> 
> could go into your crontab and run (say) once a day or so. If you simply
> wanted to rejuvenate messages that were deferred due to quotas, you
> could hook something into repquota.
> 
> 3. Finally, to "try as quickly as possible", consider using ngrep
> 
> ngrep -s 65535 EXPUNGE 'tcp dst port 143' 2>&1 |  awk '{ if ($0 ~ /^T/)
> { print "pkill -ALRM qmail-send" } }' | sh
> 
> Substituting the "pkill -ALRM qmail-send" for whatever you use to tell
> your MTA to retry deliveries as soon as possible.
> 
> 
> For the record, you'll note that dovecot isn't involved in any of this,
> but your MTA needs to do three things:
> 
> 1. The Right Thing when write() fails and we're updating the INBOX
> 2. Provide a way to restart at least local delivery as soon as possible
> 3. Provide a way to rejuvenate messages
>