Over quota mailboxes - how to notify sender immediately?

[spaceman]

If I send an email to someone, but their mailbox is full or over quota, then it would be nice to know sooner rather than later that this is the case, otherwise I'm thinking that they received my email successfully.

How do I tweak exim to ensure that it sends an email advisory instantly to the person who sends an email to a full POP account on my server?

Thanks!

 

[PWSowner]

I believe the only way to make the notice be sooner would be to reduce the mail queue holding time. That's when a message is sent back to the sender is when the queue expires and the message wasn't sent.

 

[jogjabox]

Hello,

I prefer to checkmark the options: "Discard emails for users who have exceeded their quota instead of keeping them in the queue" on exim configuration on WHM.

This way, sender knows instantly whenever the recipient is unable to receive emails. This is very good especially for critical emails which need prompt responses from recipient.

Thanks

 

[spaceman]

Thank you both for your suggestions.

I guess whichever option you try, there's one issue you have very little control over: whether or not the mail delivery failure message ends up in the spam box of the sender!

 

[spaceman]

I believe the only way to make the notice be sooner would be to reduce the mail queue holding time. That's when a message is sent back to the sender is when the queue expires and the message wasn't sent.

Hmmm. It seems amazing to me that there's not an option to notify the sender immediately that the email they sent has not yet been delivered because the recipients inbox is over quota.

I'm tempted to try the "Discard emails for users who have exceeded their quota ..." option, but this is a little like cutting of your nose to spite your face: choosing this option would succeed in notifying the sender immediately of the delivery failure (assuming it got past their spam box), BUT it's not so helpful for the intended recipient who would prefer to have all that backlogged mail straight away after he/she adjusted the mail quota.

Surely there's an exim tech-head out there who can come up with the right solution for customers???

 

[PWSowner]

Surely there's an exim tech-head out there who can come up with the right solution for customers???

That would be Chirpy. If there is a better option he's one of the ones likely to know.

 

[chirpy]

My view is that you have a quota for a reason. If a user allows their mailbox to exceed it, that's their problem, they should either remove the mailbox quota, increase it or purchase more disk space from you. IMO it's the end users problem, not yours in trying to "fix" something that is working correctly in the context of quota management. Disk quotas aren't forgiving (if the user uses up all their web space) so I don't see why mail should be different. I think luser education would be my approach Sorry for the non-technical reply.

 

[jogjabox]

I guess whichever option you try, there's one issue you have very little control over: whether or not the mail delivery failure message ends up in the spam box of the sender!

AFAIK, in this case (discard immediately), exim will not bounce message for overquota, so don't worry about ends up in sender's spam box .

 

[spaceman]

My view is that you have a quota for a reason. If a user allows their mailbox to exceed it, that's their problem, they should either remove the mailbox quota, increase it or purchase more disk space from you. IMO it's the end users problem, not yours in trying to "fix" something that is working correctly in the context of quota management. Disk quotas aren't forgiving (if the user uses up all their web space) so I don't see why mail should be different. I think luser education would be my approach Sorry for the non-technical reply.

What better education could there be than a customer calling me to say "I'm trying to send you an email with a big attachment but I'm getting this bounced message back saying that your mailbox is over quota. What gives?"

In the event that I receive a call like this, what's likely to happen? Answer: I'm going to take steps to provide more mailbox space so that I can receive this email from my customer. I'm either going to manage this myself via cPanel, or get assistance from the company that provides me with the mailbox - which may include upgrading to a more generous hosting account.

But if the person sending the email doesn't get this message, none of the above takes place!

If I send a parcel by snail mail to a client then generally speaking I'd assume that it's been received. But if I get a message back from the Post Office to the contrary, then I can take action. Without that message back from the Post Office, the sender is thinking "when's Fred going to give me a call about that package I sent him?" and Fred, the intended recipient is thinking "where the hell is that package that Bill said he was sending?". Both Bill and Fred are very busy people and are too busy right now to start conducting their own investigations and leave it until they really need a resolution on that package before making calls. Not good.

In other words, IMHO, the very best user education is
* Prompt (the moment an email server rejects a message because of over quota problems)
* Plain English (let's give the customers the best possible chance of understanding what's going on)
* Automatic (so that, in a perfect world, us techs don't have to get involved).

In summary - agreed, disk quotas aren't very forgiving and are working exactly as intended, but how about we promptly TELL people that what they expected to happen hasn't happened? Am I missing something here? Or am I just too customer-focused and should get back in touch with my tech roots?

 

[spaceman]

AFAIK, in this case (discard immediately), exim will not bounce message for overquota, so don't worry about ends up in sender's spam box .

Bugger. Can anyone confirm or deny this authoritatively? I was gearing up to try it on the understanding that it would alert senders immediately. Holding off now.

Thanks.

 

[spaceman]

Some discussion on the issue over here:

http://www.timj.co.uk/linux/rcpt-time-quota-maildir.php

 

[shacker23]

IMO, a much better option is to give the user plenty of warning that their mailbox is *nearing* quota so they can take steps before it becomes a problem. Here's a script that takes care of that:

http://hosting.birdhouse.org/scripts/checkmailquota.txt

Chirpy, the problem with the "user education" view is that a single customer may be (and often is) a business owner with multiple domains and lots of employees, each with their own mailbox. For the measly monthly or yearly hosting fee, you may end up with dozens of uneducated (or uneducatable!) users who are pissed off that mail isn't arriving, and call the admin first for support rather than the account owner (often the account owner is clueless too). Unfortunately, the reality is that interacting personally with over-quota mail users just isn't cost-effective. And people expect computers/servers not to break their lifeline to the world without proper warning. That's why I feel strongly that something like checkmailquota should be built into cpanel.

 

[chirpy]

Yup, true. If cPanel would modify their router code, such a feature exists in exim to warn on mailbox %age use too.

 

[spaceman]

IMO, a much better option is to give the user plenty of warning that their mailbox is *nearing* quota so they can take steps before it becomes a problem. Here's a script that takes care of that:

http://hosting.birdhouse.org/scripts/checkmailquota.txt

Chirpy, the problem with the "user education" view is that a single customer may be (and often is) a business owner with multiple domains and lots of employees, each with their own mailbox. For the measly monthly or yearly hosting fee, you may end up with dozens of uneducated (or uneducatable!) users who are pissed off that mail isn't arriving, and call the admin first for support rather than the account owner (often the account owner is clueless too). Unfortunately, the reality is that interacting personally with over-quota mail users just isn't cost-effective. And people expect computers/servers not to break their lifeline to the world without proper warning. That's why I feel strongly that something like checkmailquota should be built into cpanel.

Thanks for that.

Hypothetical situation:

A user has a POP account limit if 10Mb
POP account has 5Mb of mail in it, therefore account if 50% full.
Someone tries to send an email to this POP account with a 10Mb attachment.

Given the above scenario, this is my understanding and experience of what will happen:
1. The recipient POP account will reject the incoming email because 5+10 = 15Mb which is > 10Mb
2. The sender of the email will get notified that the email they sent cannot be delivered because the target POP account is over quota.
3. The owner of the target POP account will be blissfully unaware that email is not getting through to them. The only way they will find out is if the sender takes the time to alert them to the problem.
4. Exim will attempt to deliver the mail again and again for up to 5 days in the hope that either the target POP account is cleared down and/or the quota is increased such that the size of the incoming message plus the existing storage does not exceed the quota limit.

Assuming all this to be correct, then I have a problem with #3. The checkmailquota script is a step in the right direction, but it will not solve #3. What would be ideal would be for a short text email to be sent to the target POP account advising the owner that a message cannot be received because of this problem, and what steps should be taken to resolve the problem. In other words, checkmailquota will alert the owner that there MAY be a problem, whereas the script I'm suggesting would alert the POP account owner to the fact that there IS a problem.

Any comments or suggestions? Could a script like the one I'm suggesting be written? It would have to actively work with the undelivered exim mail queue, i.e. advisory emails would be generated each time exim tried to re-send the message.