[Exim] Exim + Procmail + Cyrus IMAP = quota headaches. Idea…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Jacot
Datum:  
To: exim-users
Betreff: [Exim] Exim + Procmail + Cyrus IMAP = quota headaches. Ideas?
Hi there,

We're using exim (3.03), procmail, and Cyrus IMAP on a FreeBSD system to
deal with mail on campus. The system appears, in these early stages,
to be working very reliably indeed, but I've got a problem lurking not
too far down the line, and that's to do with mailbox quotas.

The catch in all of this is that in our configuration, exim doesn't
talk directly to Cyrus' "deliver", which presumably could communicate
the existence of a Cyrus mailbox quota or threshold exception directly
back to exim, which would then either queue or bounce the offending
message... instead I've got exim talking to a system wide procmail
filter, mainly in order to deal with vacation type processing on a semi
"sealed" server. The last rule in this procmail filter then invokes
final delivery to Cyrus, and into the somewhat unorthodox "mailbox"
structures used by it.

With this sequence, namely exim -> procmail -> Cyrus "deliver", the
immediate quota related feedback to the MTA is lost, and some testing
I've done shows that quota blocked messages silently evaporate.

Given a certain perspective, of course, this is quite an attractive way
of dealing with the whole issue of disk space filling up, but it's not
particularly user friendly or conducive to keeping your job.

I'm wondering if anybody has experience in this particular aspect, or
has ideas on how to work around it? My first fairly rough and ready
"solution" would be to have a perl script checking Cyrus mailbox quotas
at regular intervalsm and mailing users above a certain utilisation
level to warn them that their incoming mail is about to start disappearing.
While not ideal, it's infinitesimally better than what I've got at present.

Another possibility, which I haven't thought through very clearly,
would be some sort of transport that attempted to do a pseudo delivery
directly to Cyrus, which could then work out if the delivery would fail,
and if so, hold or bounce the message. If this transport could, in fact
deliver the mail, it would then pass it on to the real transport, that
would call up procmail to do all it's fiddling. Is this type of
mechanism feasible? Or is there a better/different way, even within
procmail?

Any hints, pointers, references or fully worked examples gratefully
received!!

Many thanks,
-- 
F.F. Jacot Guillarmod - Information Technology - Rhodes University - Grahamstown
    Internet: Jacot@???  Phone: +27 46 603 8284  Fax: +27 46 622 7764
   The views expressed above are not necessarily those of Rhodes University