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