Being nothing more than a leech on this, Todd, I will be glad to hear from your test results. We were facing a similiar situation in our center and we had to change some end user rules. If your tests go OK then I think we will change to the same scenario that you describe.
Thanks,
On 2/8/06, Todd Piket <todd@mtu.edu> wrote:
Curtis,
Point 1 is/was taken into consideration, but we don't actually want the INBOX to remain in /var/mail/%u so using that feature of Dovecot doesn't get us anywhere at MTU.
Point 2 however has definitely piqued my interest. I will be exploring both options with enthusiasm starting tomorrow. Thank you so much for your ideas in this regard. As a Dovecot newbie I am not yet as familiar with it as you and others on this list are. I forgot that it does indeed spawn a binary that I can easily wrap.
Again I thank you. This will probably do the trick though if anyone else would like to chime in I'm still all ears.
Regards,
| Todd Piket | Email: todd@mtu.edu | | Programmer/Analyst | Phone: (906) 487-1720 | | Distributed Computing Services | | | Michigan Technological University | |
Curtis Maloney wrote:
Todd Piket wrote:
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.
Two points.
There's nothing to say /var/mail/%u can't be mbox. Dovecot already supports the INBOX being a different format to the rest of the mail. Handy if you don't run a Maildir capable LDA (but who does that? :)
Maildir was designed to not need locking. If dovecot tries to move a mail out of /new, it knows implicitly that the LDA is finished with it. This is because the LDA doesn't rename() new mail into /new from /tmp until it's finished writing it.
For some reason I recall there being an "on login" script hook possible with dovecot - if nothing else, just wrap the imap binary. This script could iterate over the /var/mail/%u/new/ directory, moving each file to ~/Maildir/tmp, then /new, and bailing out when it hits quota full.
Or am I missing some complexity here?
-- Curtis Maloney cmaloney@cardgate.net
--
Erick Perez Linux User 376588 http://counter.li.org/ (Get counted!!!) Panama, Republic of Panama