On 22 May 2012, at 21:00, Todd Lyons wrote:
> On Thu, May 17, 2012 at 6:40 PM, Todd Lyons <tlyons@???> wrote:
>>> message never got generated because the state of the mailbox never was
>>> in the range of 90-99%, where it would be detected and the warning
>>> message generated. I've not yet evaluated whether this is actually
>>> the flow of the code, so take it with a grain of salt.
>> It appears that this can in fact happen. The fix seems like it would
>> need to be one additional check along the lines of this pseudo-code:
>>
>> if ( quota_is_not_inclusive AND
>> current_size < quota_warning_size AND
>> current_size + incoming_msg_size > quota )
>>
>> then do the warning message
>
> After thinking about this, I don't think it's wise. First, I can't do
> it without adding a bit of complexity. Second, the code currently
> explicitly cancels the quota warning if quota limit is hit. Thinking
> through it, here is what will happen if we did add this:
> 1. User has about 88% mailbox used.
> 2. Quota warning message is set at 90%.
> 3. A message attempts to be delivered that would put it over quota.
> It's tempfailed and the remote queues it.
> 4. Exim generates a quota warning message into user's mailbox.
> 5. The remote attempts to redeliver a few minutes or an hour later, #3
> and #4 happen again.
> 6. ...and again.
>
> The user would log in to his mailbox the next day or after a weekend
> of this and find 20+ quota warning messages that said his mailbox was
> more than 90% (depends on your custom text exactly what it does say),
> but when he looks at the size, it's actually still below that 90%
> mark. It confuses the user, it will confuse any tech support who are
> trying to help him, and it might even confuse the sysadmin. It
> sounded like a nice idea at first, but the more I think about it, I
> think it's doing exactly what it should in a very concise and
> conceptually clear manner.
>
> The only real fix for this is some combination of:
> 1. Set your quota warning lower, giving it more breathing room to
> accept large messages.
> 2. Set your mail server to accept not quite as large messages so it
> can't overrun that space between threshhold and max_quota.
> 3. Tell your users to use cloud storage for sharing files instead of SMTP.
>
> ...Todd
I think that what you have to do is deliver the message that puts the user over the warning threshold, and make sure there's still room for a warning message. That is, the difference between the warning threshold and the non-delivery threshold should be large enough to deliver the largest acceptable message (often 50MB these days) and a small warning message.
You could also refuse to accept new message submissions from the user if they're over a third threshold (between the "warning" and "non-delivery" thresholds). Exchange does that, and so could Exim if it can get the current usage and quota for a user. The gotcha here is that clients usually won't display the SMTP error message, so you might want to deliver another quota error message to the sender's INBOX.
These might be reasonable thresholds. Though you could raise them proportionately to 10GB/user.
non-delivery quota: 1GB
cannot-send threshold: 950 MB
warning threshold: 900 MB
In fact, you might have several warning thresholds, if you wish.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
