Mailbox full message?

[Weiyi]

I was wondering would a sender receive a "Mailbox full" error message when attempting to send emails to a mailbox which has reached its quota

[jimcarter]

Yes they will,
once a user reaches their email quota it will bounce back the emails to the sender and include in the error message that the user has reached their quota
Thanks

[Weiyi]

hi thanks for the reply...then its weird that my mailboxes doesn't do that, the rougue mail simply disappears when I'm trying to send it into a full mailbox. It doesn't rebound nor gets into the inbox....any ideas what might be wrong? tks

[Silver_2000]

On the shared server I was on it took 4 days for the mail to bounce... It apparently keeps retrying for 72 hours

The worst part is the user never knows they are over their quota unless/untill someone sending them email gets a bounce message and then calls them and tells them

;-(

Doug

[gic]

Cpanel 6 sends an email to the account when it is like 80% full so that they know.

[Website Rob]

Correct my if I'm wrong, but notice of 80% usage is only sent out if that option has been turned on -- in the 'root' WHM.

Can anyone confirm otherwise?

[ozzi4648]

Originally posted by jimcarter
Yes they will,
once a user reaches their email quota it will bounce back the emails to the sender and include in the error message that the user has reached their quota
Thanks

I doubt that. One of our users has reached her quota with 278 email messages waiting. She had no idea her mailbox was full until we logged in an changed the quota for her account ourselves!

[Annette]

The option from WHM must be set for users to receive that message (although, if they're using a mailbox at their domain, and they're out of space...).

Weiyi, exim will by default attempt to redeliver mail that reaches the server for four days before returning the mail to the sender. Until the time the mail is delivered or returned, it will be spooled in /var/spool/exim/input. The sender will receive delay notifications at certain intervals until the retry time has been reached, at which time the original message will be returned to them.

[jcsolutions]

Originally posted by ozzi4648
I doubt that. One of our users has reached her quota with 278 email messages waiting. She had no idea her mailbox was full until we logged in an changed the quota for her account ourselves!

How can you update the quota for a certain email address? I have a client who setup their email addresses with 10MB quotas, yet their disk space allowance is 300MB. Now they aren't getting all their mail because their email space is all used up.

[Weiyi]

its been a couple of days now and still no rebounded mail. Really wondering whats wrong? thks for all help thus far

Originally posted by Annette
The option from WHM must be set for users to receive that message (although, if they're using a mailbox at their domain, and they're out of space...).

Weiyi, exim will by default attempt to redeliver mail that reaches the server for four days before returning the mail to the sender. Until the time the mail is delivered or returned, it will be spooled in /var/spool/exim/input. The sender will receive delay notifications at certain intervals until the retry time has been reached, at which time the original message will be returned to them.

[Annette]

Check in /var/spool/exim/input - anything with a -D is the detail of the message that's spooled, and -H is the header (where you can see the person to whom the mail is supposed to be delivered). You can also watch the exim log roll live:

tail /var/log/exim_mainlog -f

And force exim to go through the queue to attempt delivery:

/usr/sbin/exim -qff

Exim will process all the items in the spooler, and you can watch for errors on delivery to the account you're concerned about. If there's nothing in the spooler for that person, there won't be anything in the logs, of course.

There are a couple of reasons for no bounce:

1. The user actually had the mail delivered, but not to the mailbox to which they thought it would be delivered.
2. The user has some filtering set up that blackholed the mail upon arrival, which negates both delivery and bounce.
3. The bounce was sent, but never made it to the original sender due to any one of a variety of reasons (bad sender address, bad headers, filtering at the sender's end, filtering at the provider's end, etc.).

Ideally, what we'd do in this situation is try to send the user some mail while watching the mail log roll by to see what happens. Sometimes a fresh test is more productive.

[Juanra]

Also the test mode of exim can be very useful:

/usr/sbin/exim -bt -d5 john@example.com