Best practices for checking quotas?

interfasys

interfasys

Verified User
Joined
Oct 31, 2003
Messages
1,710
Location
Switzerland
I've been doing some reading on mail servers these past days and one thing that seems to divide people is how to deal with messages that are sent to an account that is over quota.

Currently, Exim stores the message, doesn't say anything to the sender, nor the recipient and, I think, sends a permanent failure a few days later if the account hasn't made room for it.

The first problem that comes to mind is that, by default, neither the sender, nor the receiver are notified, so unless they have another way of communicating, nobody will know about the failure.

This can be fixed in a number of ways, but what would be the best one?

Check at SMTP RCPT time and send a bounce?
Check at routing, transport or delivery time? Notify the sender? The recipient? Both?

The issue with bounces is backscatting, but sending a bounce 4 days later doesn't really solve that, if anything, it makes it worse. And if we send bounces for other reasons, there shouldn't be one for not sending messages about quota issues.

Notifying the recipient seems difficult if the mailbox is full, unless we can define vip messages that would go through anyway.

So, who has any thoughts on the issue?
 
Exim keeps the incoming mail in the queue because we (all of us) want to get our mail, and the presumption is that the error is temporary (it may even be in an RFC somewhere; I haven't checked).

However, as you point out, we don't check, especially on a shared server.

The right way to do it, in a world where the email could be spam from an innocent email address, is to refuse the email at receipt. That would notify the sender. I don't know if it's easily doable, but I suppose you could check for us :).

Jeff
 
I think the RFC says that you have to notify the sender, but I'll check again.
If you mean have the LDA send the message, then it's easily doable with Dovecot (one line) and I'm sure there is a switch you can use in Exim.
 
I normally get an email back immediately telling me the mailbox is full and that I need to try again later.
 
Hmmm... thinking about it, I believe I do, too. Care to check through the exim.conf file and see?

Jeff
 
floyd said:
I normally get an email back immediately telling me the mailbox is full and that I need to try again later.
Click to expand...

I mean when sending to other email servers, not my own. I have not encountered a mailbox full problem on my own servers yet. I was speaking on what I believe to be "normal" behavior. Whether the exim we use is normal or not I do not know.
 
In the current Exim config, the first notification happens 24h after the delivery failed. Nothing is sent when Exim identifies that it can't store the message.
I think it's pretty bad, because a sender will expect the message to have been delivered if he didn't get an error message.
So, maybe what could be done is to send an error message while still queue the message? Rejecting it at delivery time is a waste of bandwidth as data will already have been transmitted.
 
That 24 hours is actually much better than defaults in exim and other mail-servers; most wait up to four days. I don't know if it's in an RFC or just a custom, but I decided a long time ago it was way too long to wait.

User interfasys is correct; you can't reject at until after you've received the entire message because exim doesn't try to deliver until it's got the message.

I don't know if there's any way to warn and send the message; feel free to check with the good folk on the exim-users mailing list and post back.

If you want to make sure your user gets the message you can turn on read notification or delivery notification in most MUAs. Of course many MUAs ignore the request for notification, or give the recipient the choice of returning a notification, all in the name of privacy.

I don't know if there's an easy solution.

I look forward to you checking with exim-users list and finding out for me :).

Jeff
 
It permanently fails after 4 days, but you get a reminder every 24h.

I did some digging. No matter what you decide (reject or just warn the sender), you need to do it at RCPT time if you don't want to play in the hands of spamers, unless you have a very good system that knows when not to send messages back to what's written on the envelope.

Doing that check at that time is not possible while using purely an Exim configuration.

So, there seems to be 3 ways of taking this forward:
  1. No changes. The system rejects or defers the message at delivery time like it's done now and the admin accepts the fact that he may send spam if additional checks are not performed
  2. DA completely rethinks the way they deal with quotas and implement them in MySQL per example. That way, DA, Exim and Dovecot all have access to those numbers
  3. We make sure the server knows when to send a message back to a real sender
 
My solution is to not use the kernel quotas at all. With space being very cheap it does not make much sense to me. Yes that is just my opinion for whatever its worth.
 
Works as long as you don't provide any backups...
100GB of data x 30 days' worth of backups = 3TB, just for one server ...that doesn't come cheap in my books
 
interfasys said:
Works as long as you don't provide any backups...
100GB of data x 30 days' worth of backups = 3TB, just for one server ...that doesn't come cheap in my books
Click to expand...

Not using quotas is simply one option. No one choice is going to be right for everybody. I do not enforce quotas and I do make backups.
 
You must log in or register to reply here.
Back
Top