Notify admin and user if user exceeds the email limit

Ok just received an email from my server:

Server limit: 250

Amount emails | Account name
627 | giorgia
311 | nonpresent


No ticket in DirectAdmin, just this email once an hour.

Code: 
>cat /etc/virtual/limit_giorgia
5000
>cat /etc/virtual/limit_nonpresent
5000
>cat /etc/virtual/limit
250

As you can see, the error come counting on the limit file without take consideration of the per-user one.

Should be cause im not using the pre-release binary?
 
Hello,

1) If this is the actual message you're getting
Code: 
Amount emails | Account name
401 | dndonline
387 | unknown
365 | mhorpheox
392 | giorgia
1040 | nonpresent
then I'm not sure that's "our" message. I don't recall forming any message in that format, and we don't do any hourly checks. All notifications would be sent through the DA message system, so you see it when you click "Messages" at the top right. It could be some other email tracking system that isn't ours. You'd need the pre-release binaries to get notified (with the per-minute check)... so I don't think that's ours, if you've got the standard non-pre-release binaries.


2) With the new exim.pl, you'll be able to tell if it's working as it would create:
/etc/virtual/mail_task.queue

for the dataskq to process. Without the pre-release dataskq, the mail_task.queue file will just sit there, and won't be deleted.. but you can look at it's contents to see if it's adding the line that looks something like this:
Code: 
action=limit&username=$name&count=$count&limit=$email_limit&email=$sender_address&authenticated_id=$authenticated_id&sender_host_address=$sender_host_address

3)
failed to expand condition "${perl{check_limits}}" for lookuphost router: Undefined subroutine &main::check_limits called.
failed to expand condition "${perl{save_virtual_user}}" for virtual_user router: Undefined subroutine &main::save_virtual_user called
Click to expand...
Are you *sure* you've got this /etc/exim.pl?
http://files.directadmin.com/services/exim.pl

Also ensure the exim.pl is chmod 755 (not sure if it really matter, but that's what I've got).

John
 
Yes, is latest release downloaded from the same link you provided

Code: 
>ls -l /etc/exim.pl
-rwxr-xr-x 1 root root 7758 25 feb 04:38 /etc/exim.pl

Ive added the action to the mail queue aswell.

Relating to sender verify now is not working again... worked for about 20/30mins just fine and now stop again with same errors

No message on DA Message System but just that email.

Also ive found where this email come from :)

Was a script i was running with crontab and i forget to have:

Code: 
GNU nano 1.3.12                                         File: /root/check_email_limit.sh

#!/bin/sh
EMAILADDRESS="[email protected]"
# Syntax excludelist for multiple users: .USER1\|USER2\|USER3.
EXCLUDELIST='admin'
MAX=`cat /etc/virtual/limit`
AMOUNT=`find /etc/virtual/usage/ -not -name "*.bytes" -type f -size +${MAX}c | grep -v ${EXCLUDELIST} | wc -l`
if [ ${AMOUNT} != "0" ]; then
EMAILMESSAGE="/tmp/emailmessage.txt"
echo "Server limit: ${MAX}" > $EMAILMESSAGE
echo "" >> $EMAILMESSAGE
echo "Amount emails | Account name" >> $EMAILMESSAGE
find /etc/virtual/usage/ -not -name "*.bytes" -type f -size +${MAX}c -printf "%s | %f \n" | grep -v ${EXCLUDELIST} >> $EMAILMESSAGE
mail -s "Spammer detected" ${EMAILADDRESS} < $EMAILMESSAGE
rm -f /tmp/emailmessage.txt
else
echo "No spammers"
fi

So, ok, this email have nothing to do with the real da funciont and was saying prolly something not true.

Now ill check the mail.queue if is working.

If the limit is working correctly and that script was moving me out from the truth so ive disturbed for no-reason.

The only problem so, should be the sender verify option that i had to disable again.

Thanks for your help.

Regards
 
Just for be sure, those are the first lines of exim.pl im using:
Code: 
#!/usr/bin/perl

#VERSION=6

#smtpauth
#called by exim to verify if an smtp user is allowed to
#send email through the server
#possible success:
# user is in /etc/virtual/domain.com/passwd and password matches
# user is in /etc/passwd and password matches in /etc/shadow
 
I'm getting a lot of these:

Code: 
2011-03-01 13:53:37 1PuP57-0005uF-IL failed to expand condition "${perl{check_limits}}" for lookuphost router: You (unknown) have reached your daily email limit of 250 emails
2011-03-01 13:53:37 1PuP51-0005u5-Hx <******@******.***>: spamcheck transport output: 2011-03-01 13:53:37 1PuP51-0005u8-KN failed to expand condition "${perl{check_limits}}" for lookuphost router: You (unknown) have reached your daily email limit of 250 emails

the failed to expand condition part is the usual part though still maybe worth to check exim.pl to fix this?

The other part I don't get, why doesn't it detect the user correctly (obviously the ******@******.*** was a normal email address)? It's a standard domain on the server, like any other, but since this domain and some others are sometimes detected as user "unknown" they hit their email limit pretty quickly.
 
Last edited:
Ok, first message from DirectAdmin panel at 00.17 (so seems is not checking every minute)

There have been 668 outgonig emails yesterday from the giorgia User account.
There could be a spammer, the account could be compromised, or just sending more emails than usual.

This warning was generated because the 250 email threshold was passed.

Code: 
>cat limit_giorgia
5000
>ls -l limit_giorgia
-rwxr-xr-x 1 mail mail 5 24 feb 16:06 limit_giorgia

Definitly the limit per-user isn't working at all :)
 
Hello,

1) That's the per-day message. It's in the 1.37.0 version, but is also in the pre-release version. There are 2 different checks.. the minutely one, and the per-day one.

2) Only the pre-release binaries know what the limit_user file is.


Using the current stable binaries only checks the /etc/virtual/limit, and only has a per-day check. (hence the "yesterday" part of the message).

John
 
So isnt necessary just the exim.pl file as i supposed.

Ok :)

One question, in a production server is "trusteable" to use the pre-release?
If any error occur with pre-release there is a way to go back to stable one?

Regards and Thanks
 
We've been using the pre-release binaries on one of test boxes and I have not (yet) found any issues (live box with website on it).

And yes, going back is easy. The pre-release binaries will be downloaded as "new.tar.gz", and the stable binaries are downloaded as "update.tar.gz". If you want to go back, just extract the update.tar.gz, type "./directadmin p" and restart DA.

John
 
Thanks a lot.

Update done and received some notification.

Here one:


The giorgia account has just finished sending 500 emails.
There could be a spammer, the account could be compromised, or just sending more emails than usual.

After some processing of the /etc/virtual/usage/giorgia.bytes file, it was found that the highest sender was [email protected], at 1091 emails.

The top authenticated user was giorgia, at 1091 emails.
This accounts for 218% of the emails. The higher the value, the more likely this is the source of the emails.
An authenticated username is the user and password value used at smtp time to authenticate with exim for delivery.


The most common path that the messages were sent from is /var/log/directadmin, at 939 emails (187%).
The path value may only be of use if it's pointing to that of a User's home directory.
If the path is a system path, it likely means the email was sent through smtp rather than using a script.

This warning was generated because the 500 email threshold was hit.

================================
Automated Message Generated by DirectAdmin

Code: 
>cat /etc/virtual/limit_giorgia
5000
>cat /etc/virtual/limit
250

the curios thing is:
This warning was generated because the 500 email threshold was hit.

When the default limit is 250 and that user limit is 5000 where did he found 500? :)

Regards
 
Another thing maybe useful:
Code: 
>ls -l /etc/virtual/usage/giorgia*
-rw-rw---- 1 root mail   1092  2 mar 09:48 /etc/virtual/usage/giorgia
-rw-rw---- 1 root mail 192483  2 mar 09:48 /etc/virtual/usage/giorgia.bytes

Thanks
 
Hello,

The limit is given to DA via:
/etc/virtual/mail_task.queue

That is filled from the /etc/exim.pl, which gets it from the /etc/virtual/limit_user file.

Note, that the mail_task.queue could have been sitting around there with an old limit for some time if you've got the new exim.pl a while ago, but just got the new binaries.

Also, if the usage/user.bytes isn't emptied at the same time as user/user, then you'll get those skewed numbers and % values.

You can see what's going on in the exim.pl by checking the function:
Code: 
sub check_limits
eg:
Code: 
        if (open (LIMIT, "/etc/virtual/limit_$name"))
        {
                $email_limit = int(<LIMIT>);
and
Code: 
                        open(TQ, ">>/etc/virtual/mail_task.queue");
                        print TQ "action=limit&username=$name&count=$count&limit=$email_limit&email=$sender_address&authenticated_id=$authenticated_id&sender_host_address=$sender_host_address\n";
John
 
Ok, thanks for clarification.

I had already checked that file before upgrade and there was line there, so, exim.pl alraedy had filled it many times but queue never runned.

Regarding this

Code: 
Also, if the usage/user.bytes isn't emptied at the same time as user/user, then you'll get those skewed numbers and % values.

What do you mean for emptied at time as user/user?

Is suggested to remove all those file and let directadmin create and start over the count for be sure?
Does those file are removed/cleaned automatically once a month/day?

Regards
 
The usage/* file are dumped out nightly.

The reason for the skew is if the user.bytes is left alone, but the "user" file is deleted and re-filled. The user.bytes would have more emails there .. so once the limit is reached again, the user.bytes file could have (for example) double the number of emails as the limit. The count is taken from the user.bytes, and the limit is lower.. thus you get the "more than 100%" values. You don't need to worry about that too much, I saw it quite a bit during my testing when I was manually deleting the usage/user file to have it get refilled (but left the user.bytes file alone, since I didn't care about the % at that time).

Anyway, removing both would be the cleanest way to get an accurate test of the system. Let them fill up on their own naturally.

Note, they will be removed by the tally each day.

John
 
I have a feeling that "unknown" is the sender_verify username, eg:
Code: 
        $name = getpwuid($uid);

        if (!defined($name))
        {
                $name = "unknown";
        }
Meaning all incoming emails will have a sender verify.. and all sender verify checks will be billed as an outbound email to "unknown".. thus (if my theory is correct), means you'll be allowed /etc/virtual/limit number of incoming emails. Not likely what we want.

I've just updated the exim.pl again to:
return "yes";

and not check the limits if the $name is unknown, so give it a try. (my testing didn't have the sender-verify on.. so I might poke at this case more)

John
 
Well, regarding the verify = sender option in exim.conf i still have to disable it for make customer receive email without problem...

Ill download the latest exim.pl right now
 
I've just confirmed the same thing. I've got the sender verify enabled and I'm not getting "unknown" anywhere. It could be a perl issue for some cases... (just not sure which)

@SeLLeRoNe:
I'd be very curious to see what you've got in your file:
/etc/virtual/usage/unknown.bytes

to see if we can get any message ID's from it to see what's generating the unknown user. Ie: why is the $uid not returning a defined username from getpwuid.

I'm going to remove the return "yes" for the unknown case (for now), in case it's a spammer doing something creative to block us knowning what's going on.

John
 
For example:

Code: 
2011-03-01 13:53:37 1PuP51-0005u8-KN failed to expand condition "${perl{check_limits}}" for lookuphost router: You (unknown) have reached your daily email limit of 250 emails

2011-03-01 13:53:37 1PuP51-0005u8-KN ** r*******@gmail.com <[email protected]> F=<v******@remotedomain.com>: Unrouteable address
2011-03-01 13:53:37 1PuP51-0005u8-KN failed to expand condition "${perl{check_limits}}" for lookuphost router: You (unknown) have reached your daily email limit of 250 emails

2011-03-01 13:53:37 1PuP51-0005u8-KN ** r*******@gmail.com <[email protected]> F=<v******@remotedomain.com>: Unrouteable address
2011-03-01 13:53:37 1PuP57-0005uF-IL <= <> R=1PuP51-0005u8-KN U=mail P=local S=48886 T="Mail delivery failed: returning message to sender" from <> for v******@remotedomain.com
2011-03-01 13:53:37 1PuP57-0005uF-IL failed to expand condition "${perl{check_limits}}" for lookuphost router: You (unknown) have reached your daily email limit of 250 emails

2011-03-01 13:53:37 1PuP57-0005uF-IL ** v******@remotedomain.com F=<>: Unrouteable address
2011-03-01 13:53:37 1PuP57-0005uF-IL Frozen (delivery error message)
2011-03-01 13:53:37 1PuP51-0005u8-KN Completed

Where localdomain.nl is just a local domain like any on the server. Any idea why this domain isn't detected as belonging to a local user?
 
Last edited:
You must log in or register to reply here.
Back
Top