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
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
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?
Can anyone confirm otherwise?
O
ozzi4648
Guest
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!
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.
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.
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.
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.
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.