[Dovecot] Quota handling - v2 - updated FR

[Kenny Dail]

> > How is this different from just telling the customer there quota has
> > been increased by the size of their .oqt box?
> 
> 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 they know that they can leave without cleaning up their mail,
because their messages will be delivered anyways. So it merely encourages
users to abuse quota. A smart user could abuse this as well, Forward
several large messages back to themselves, to put them at the end of the
queue, delete from inbox, get the new messages in, etc. Essentially
giving them extra quota.

> > Quota is there for a reason at my work, to stop accepting mail if the
> > user already has too much mail.
> 
> Currently, that is correct - 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.

Beat that customer with a clue stick? The whole I want quotas, but don't
want them seems silly. But it's their money, they can probably hire
someone to do it.

> > As we deal with customers, and can't just fire them for being too
> > stupid, it is much better to give them a clear policy with no fuzzy 
> > grey areas. I think this also better in the case of the few employees
> > I have to support as well.
> 
> Funny - I see what I am proposing as being much *more* clear, with LESS 
> fuzzy gray areas.

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.

option one is easier to explain for me.

> > 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.
> 
> This is your *opinion*. Personally, I disagree - but, of course, I would 
> never force my way on you. 

Correct, you were asking for opinions, whether or not you consider it is
up to you.

> As I have maintained, this should definitely 
> be configurable - including the option of sending a notification to the 
> sender that their message was accepted for delivery, but won't be 
> delivered to the users Inbox until they fix their quota problem.
> This means all the sender has to do is call the user and tell them 'I 
> sent you the message - it is waiting for you - fix your quota, idiot'...

Configurable is always good, and I have never disputed that. However I
doubt I would appreciate a message like that coming back to me. The only
time I would want a DSN is if the message wasn't delivered. I'd probably
mark "delivered but over-quota" messages as spam. So if you do get this
implemented be sure to opt me out of these notices if I happen to send a
message that way. :)

> > A soft bounce may take days of retrying before the sender is aware of a
> > problem,
> 
> Who is talking about soft bouncing? Did you even read my proposal?
OK I admit this is not directly part of your proposal, but this is the
"other solution" people often mention to not loosing mail that is over
quota. My soapbox got carried away, sorry for drifting.

> > The recipient is probably going to be oblivious that a problem exists
> > because if they are over quota, it usually means they haven't been
> > checking their mail and will not see a quota warning message.
> 
> True - but then they would be oblivious in either case, so I fail to see 
> your point.
The point being that extra complications wouldn't help, so why bother?
Save the disk space for something else.

> > 89% of the cases I see of users over quota, is due to negligence.
> 
> Yep... and my way, no mail is lost or bounced, it is just held pending 
> resolution of the over-quota condition, after which it is *immediately* 
> delivered to their Inbox within SECONDS.

Unless they take weeks to fix the problem, then it really isn't
delivered for WEEKS. 

> > 10% is for mailboxes that are no longer in use.
> 
> Why are you leaving an account open that is no longer in use?

While they may not be used, the customer hasn't called to close them
either.

> Admittedly, for an ISP, this may not be a good thing to do - but not 
> every mail system belongs to an ISP. I can see a lot of benefit to 
> Corporate mail systems.
> 
> > I wouldn't think it a good idea to allocate extra disk space to
> > either of these cases.
> 
> So set the hard limit on the over-quota box. But for 95+% of cases, it 
> would never get used.

Easier to set a hard limit on the mailbox. Rather than saying this is
your quota, but if you don't wish to respect that, then this is your 
*real* quota.

> > The other 1% calls us to ask for more space which we gladly sell to
> > them.
> 
> Obviously, you are selling mail services - so yes, I agree, this may not 
> be a good fit for an ISP or someone selling mail services - but maybe 
> you could comment on this from the perspective that not everyone would 
> use it like you do...
> 
> Do you seriously not see a benefit to a corporate user?

Actually no. That's just the way I am, set a rule and stick to it. If
I think the users need more space, I consider raising the quota.

> 
> I guess I'm just way off base here...

Not if you have somebody actually asking for it. But I'd seriously see
how much it is truly worth to that customer. As this really feels like a
marginal case, I don't think there will be enough others willing to
sponser it.

-- 
Kenny Dail <kend at amigo.net>