Related to http://www.directadmin.com/features.php?id=1121 Check files of size /etc/virtual/limit (or /etc/virtual/limit_user if it exists) in the folder /etc/virtual/usage/user (not the bytes files) to see if they've hit the limit, then notify the Admin with the existing code. New task.queue type file: /etc/virtual/mail_task.queue used for mail only tasks. In order for this new mail_task.queue to be filled, a new exim.pl is required: wget -O /etc/exim.pl http://files.directadmin.com/services/exim.pl You should see: #VERSION=6 or newer, at the top of the exim.pl file. If you do not update your exim.pl, the mail_task.queue won't be created and you won't get real-time (within a minute) notices of email limits being hit. Similar to id=1121, this feature is affected by the options: notify_on_mass_emailing notify_user_on_mass_emailing where an email is only sent if this is set: notify_on_mass_emailing=1 and if that is set, Admins will be notified. The option: notify_user_on_mass_emailing=1 will also notify the User that he's hit the limit. The User notification will not happen if notify_on_mass_emailing is not enabled. There is a new template for this message: email_limit_message.txt It will report on the top sender, top "auth" username, top sending IP, and top path used. Note, the path can be useful, but can also be misleading. This is because any email sent over smtp will use exim's current working path, which could be /root, /var/spool/exim, etc... it's where ever the process's "current working path" is. However, the path can also be very helpful in the case that you've got a rogue php/perl script sending emails from a client's account. In that case, the path would be the path the script is in, which would help more quickly identify the problem.