[Dovecot] Quota handling - v2 - updated FR

[David Lee]

Charles wrote:
> Because it hasn't - they can't GET this mail until they deal with their
> over-quota condition. All this does is prevent mail from being REJECTED,
> and provide a more consistent and effective way to communicate the
> problem to the user.
>
> [...] - but I have a customer who wants to ACCEPT
> the mail for delivery (ie, never, ever REJECT a message due to
> over-quota), but just not give it to the USER until they fix their quota
> problem.

For some environments, such as companies, universities, etc. this "accept
but don't yet deliver" option is a good one.  Indeed, if the incoming
email is for a legal requirement (in UK, Freedom of Information, Data
Protection, etc.) for that institution, then rejection/bounce simply
because of a temporary quota glitch could be bad practice, bad for
corporate image, and possibly even get legal if it were routine rather
than one-off glitch.

For other environments, presumably some that Kenny had in mind, a single
level is probably fine.  (But see below.)

Different customer (or user community) environments may well have
different preferences or requirements.

Charles's "accept but don't yet deliver" sounds like a good option to have
available.  Kenny's simpler "deliver or reject" may well be a reasonable
option for his environment.  This difference really lies in their human
environments, not the teechnical options or implementations.

I know it's fashionable to knock and criticise Microsoft Exchange(!) but
they have a multi-threshold quota system available.  (One of the other
thresholds is "you can't send outgoing until you get within quota" which
is less easy to translate into a dovecot, IMAP-only, environment.)
Perhaps (dare I say?!) MS have good reasons for making multi-threshold
quotas available as an option.

Kenny wrote:
> option 1: if you go over quota you will not get any more mail
> option 2: If you go over your quota you will get your mail your mail
> will fall into a bucket nobody can see, but you will get status messages
> that messages are in this bucket, with detailed instructions to follow,
> which no matter how well they are written will generate more questions.

Yes.  Two options.  Your environment may suit the first, simpler, option.
Fine.  Charles (and some of the rest of us)  would assess our different
environments as being able to benefit from the second being available in
some circumstances.


Kenny continued:
> A hard bounce is the right way to go in this case, because it will let
> the sender know right away that there is a problem sending to the user.

For some environments (e.g. users at a mass-market ISP) this may well be
appropriate.  For other environments (e.g. the financial/legal department
within that same ISP) that probably is far from ideal.

In ITIL terms: two different (and necessarily different) Service Level
Agreements (SLAs) for two different customer groups, whose implementation
could be greatly eased by the availability of a multi-threshold quota
option (perhaps used for one group, not the other).

Hope that helps.



-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:  UNIX Team Leader                         Durham University     :
:                                           South Road            :
:  http://www.dur.ac.uk/t.d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :