Inactive account (suspended) still sending lots of spam mails?

Maybe you can try this.
Unsuspend the user billing.
Wait a couple of minutes. Check if the billing/domain.com_off is gone.
Check if there is no suspension set from the useraccount itself. <-- this might cause the billing.domain.com file.
If present, unsuspend the domain from user ofcourse. Wait a couple of minuts.
Suspend the account again as admin. See if things are now correctly blocked.
 
Richard G said:
Check if there is no suspension set from the useraccount itself. <-- this might cause the billing.domain.com file.
Click to expand...

When an individual email account is suspended an exclamation mark (!) is added the the mail passwd file for that user. (billing:!......)

When a user account is suspended all of the domains for that user are renamed to _off in /etc/virtual.

The only way to have billing.domain.com in /etc/virtual is for it to be a subdomain.

I think he has something weird set up and not normal and he is not telling us everything. I wish people would give us real information so we could really help.

login:billing
Click to expand...

That means the spammer used a system account and not a virtual email account so /etc/virtual is not relevant.

Check the /etc/shadow file and see if the entry for billing has an exclamation mark (!) after the colon :)) like billing:!...... It possible something else unsuspended the user and since DA didn't do it DA still thinks the user is suspended.
 
I looked at the shadow file and it correctly states: billing:!$6$P...
So with explanation mark.

I don't have anything special set-up and I am certainly not hiding anything!
This is in everyones interest to get this DA bug fixed...

I haven't had it since, but still strange this could have happened.
 
Its not a DA bug since DA does not handle email. If billing indeed has the exclamation mark then billing is not sending email at least not with authentication. I think at this point you need a server admin, preferably someone very familiar with exim since it is exim that is handling the email.
 
It's odd indeed. I just tried it, just to see what happens.

First it works
A=login:mytestuser

Then after suspending

535 Incorrect authentication data (set_id=mytestuser)
 
Could be maybe done during a bug which was fixed later or some hickup appeared.
Did you try my suggestion to unsuspend and after a couple of minutes suspend again and see if it's really suspended then and not sending emails anymore?
 
Yes, it stopped sending email after unsuspending and suspending again.
 
So you checked the shadow file AFTER you suspended again?
 
What I am asking is did you check the shadow file BEFORE you unsuspended and then suspended again? What I am saying is that maybe it was not really suspended until you did as Richard said.
 
NNOOOOOO
It started again.


A new message or response with subject:
Warning: 500 emails have just been sent by billing

The user still has in /etc/shadow
billing:!$6$P

The user is still suspended.
Where are these spam mails coming from?
I get these mails every day now!


The billing 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/billing.bytes file, it was found that the highest sender was [email protected], at 500 emails.

The top authenticated user was billing, at 500 emails.
This accounts for 100% 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 top sending host was 80.82.64.147, at 500 emails (100%).

The most common path that the messages were sent from is /, at 500 emails (100%).
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.


[root@server ~]# tail /etc/virtual/usage/billing.bytes
1174=type=email&email=[email protected]&method=outgoing&id=1kKNBF-0001GP-Jf&authenticated_id=billing&sender_host_address=80.82.64.147&log_time=1600699957&message_size=1174&local_part=bearnt&domain=msn.com&path=/
1174=type=email&email=[email protected]&method=outgoing&id=1kKNBF-0001GP-Jf&authenticated_id=billing&sender_host_address=80.82.64.147&log_time=1600699957&message_size=1174&local_part=bearnindy1&domain=aol.com&path=/
 
I think that the issue is that the user "billing" is a real unix user. The file used by exim to maintain the password for real users is /home/${username}/.shadow . The authentication for smtp will use that file, so you want to make sure that it too has the exclamation point there to disable it. It will not use /etc/shadow
 
[root@server ~]# ls -la /home/billing/
-rw-r----- 1 billing mail 0 Jul 15 14:07 .shadow

It's an empty file?
 
That could be your issue. The code in /etc/exim.pl shows:
Code: 
  if (open(PASSFILE, "< $homepath/.shadow")) {
                                        $crypted_pass = <PASSFILE>;
                                        close PASSFILE;

                                        if ($crypted_pass eq crypt($password, $crypted_pass))
So if the .shadow is 0 bytes, and the user tried to log into exim without a passord, the line would look like "crypt('','')" which returns blank so the compare matches and is now authenticated. Try putting something in that file, anything at all and that should do the trick.
 
Tx, I put some weird characters in it. Do I need to restart exim to load the new password?
 
You must log in or register to reply here.
Back
Top