spam send out from my server keeps on going urgently !

its strange i change my pass to a hard pass close all mailapps on pc and phone so i never set the new password in
than after a while i do tail and see first a warning of wrong pass than directly they are in and start the spamming
i really don't understand that

2018-03-11 13:39:35 plain authenticator failed for (mail.opelmanta.be) [223.231.93.76]: 535 Incorrect authentication data ([email protected])
2018-03-11 13:39:49 1ev0GS-0004OC-MY <= [email protected] H=(mail.opelmanta.be) [223.231.93.76] P=esmtpa A=plain:alex S=3956 id=014240334293$0rfqq3by$clik6zqb$@Thai-PC T="" from <[email protected]> for [email protected]
2018-03-11 13:39:54 1ev0GS-0004OC-MY => [email protected] F=<[email protected]> R=transip_email T=auth_relay S=4874 H=vps.transip.email [149.210.149.126] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes A=auth_login C="250 2.0.0 Ok: queued as 3zzggD0Yl5z1gwtL"

if someone is sure they whould find the problem on the system feel free to contact me if you find the solution i want to donate some cash
 
Are your TransIP Mailservice credentials compromised? What does the statistics page say, how many emails are send?
 
still available to send today 853 mails
(but i think real mails send on the server maybe 10 thats all)
 
As suggested above, your Wordpress could be hacked and mails could be sent out through a malware php script. If this is the case, you could do the following:

- Try scanning your Wordpress site e.g. with WPScan (https://wpscan.org/), some plugins/themes you're using may be exploitable, even if they're assumed to be up-to-date by Wordpress.
- try grepping your public_html folder for malware scripts, i.e. search terms below could help you locate them if present:

grep -iR '\]\.\$' * -> Find strings containing '].$' (typically present in malware scripts)
grep -e '[^\ ]\{60,\}' *.php -> Find php-files containing strings with 60+ non-space characters
grep -iR "eval(" * -> Find strings containing eval'd code
grep -iR "rot13(" * -> Find strings containing string rotation encryption, used to obfuscate malware code

If there are in fact malware scripts present, it doesn't suffice to just clean everything, you also have to make sure your Wordpress isn't vulnerable anymore either or else new malware scripts will be created in a few days.
 
i scanned everything nothing found that i could make up from bad i'm not that very good in that mal finding things ;)
but i changed all wordpress installations that used that mailadres maybe if i see if the problem changes what site it was
 
You problem has to do with your exim config. You are trying to relay email through another server (vps.transip.email) but I don't think your config is not 100% correct for what you are attempting. The first thing I see, is that you have your authenticators set in the following order:
auth_login
plain
login
What that means to exim, is that it will attempt the first authenticator (auth_login) and as long as that doesn't fail it won't try any more. Since that is your first router and there are no prompts, as far as exim is concerned you are authenticated (no failures). If you move auth_login to after the login authenticator it should work.

I recommend, that instead of hacking up the directadmin supplied exim.conf, you update the 3 files recommended by in https://help.directadmin.com/item.php?id=153 . If you do that, then you don't have to keep adding those changes every time a new exim.conf is released. Plus they force the changes into the correct parts. For example in your case, this should have worked if you had the following in each of the specified files:
/etc/exim.routers.pre.conf:

transip_email:
driver = manualroute
domains = ! +local_domains
ignore_target_hosts = 127.0.0.0/8
transport = auth_relay
route_list = * vps.transip.email::587
no_more


/etc/exim.transports.pre.conf:

auth_relay:
driver = smtp
port = 587
hosts_require_auth = <; $host_address
hosts_require_tls = <; $host_address

/etc/exim.authenticators.post.conf:

auth_login:
driver = plaintext
public_name = LOGIN
client_send = : [email protected] : uqDLHowJpcFbRoBK


I also recommend you change the password for your [email protected] since you posted your config with the password still there. I have not testing these settings, but from what I see, reverting your exim.conf to stock (with the exception of uncommenting out the clamav lines) and adding the above settings to the specified files, should allow you to send/receive emails and not allow that hacker to send emails as though your server were an open relay. Also note, that you should not set server_set_id to the to your auth_relay. That potentially too could be your problem, that is what tells exim what to set $authenticated_id to.
 
You problem has to do with your exim config. You are trying to relay email through another server (vps.transip.email) but I don't think your config is not 100% correct for what you are attempting. The first thing I see, is that you have your authenticators set in the following order:
auth_login
plain
login
What that means to exim, is that it will attempt the first authenticator (auth_login) and as long as that doesn't fail it won't try any more. Since that is your first router and there are no prompts, as far as exim is concerned you are authenticated (no failures). If you move auth_login to after the login authenticator it should work.

I recommend, that instead of hacking up the directadmin supplied exim.conf, you update the 3 files recommended by in https://help.directadmin.com/item.php?id=153 . If you do that, then you don't have to keep adding those changes every time a new exim.conf is released. Plus they force the changes into the correct parts. For example in your case, this should have worked if you had the following in each of the specified files:
/etc/exim.routers.pre.conf:

transip_email:
driver = manualroute
domains = ! +local_domains
ignore_target_hosts = 127.0.0.0/8
transport = auth_relay
route_list = * vps.transip.email::587
no_more


/etc/exim.transports.pre.conf:

auth_relay:
driver = smtp
port = 587
hosts_require_auth = <; $host_address
hosts_require_tls = <; $host_address

/etc/exim.authenticators.post.conf:

auth_login:
driver = plaintext
public_name = LOGIN
client_send = : [email protected] : uqDLHowJpcFbRoBK


I also recommend you change the password for your [email protected] since you posted your config with the password still there. I have not testing these settings, but from what I see, reverting your exim.conf to stock (with the exception of uncommenting out the clamav lines) and adding the above settings to the specified files, should allow you to send/receive emails and not allow that hacker to send emails as though your server were an open relay. Also note, that you should not set server_set_id to the to your auth_relay. That potentially too could be your problem, that is what tells exim what to set $authenticated_id to.

thanks for the good explanation and the support and the thinking tonight i try this one out :) i see there is a new exim.conf out will do it with the new 4.5.8 version
will let you know if it worked thanks on advance.

i know my pass was posted in that file i changed it and changed it in the configs we will see if it works i guess i made a mistake.
But i followed my isp manual :)
 
You problem has to do with your exim config. You are trying to relay email through another server (vps.transip.email) but I don't think your config is not 100% correct for what you are attempting. The first thing I see, is that you have your authenticators set in the following order:
auth_login
plain
login
What that means to exim, is that it will attempt the first authenticator (auth_login) and as long as that doesn't fail it won't try any more. Since that is your first router and there are no prompts, as far as exim is concerned you are authenticated (no failures). If you move auth_login to after the login authenticator it should work.

I recommend, that instead of hacking up the directadmin supplied exim.conf, you update the 3 files recommended by in https://help.directadmin.com/item.php?id=153 . If you do that, then you don't have to keep adding those changes every time a new exim.conf is released. Plus they force the changes into the correct parts. For example in your case, this should have worked if you had the following in each of the specified files:
/etc/exim.routers.pre.conf:

transip_email:
driver = manualroute
domains = ! +local_domains
ignore_target_hosts = 127.0.0.0/8
transport = auth_relay
route_list = * vps.transip.email::587
no_more


/etc/exim.transports.pre.conf:

auth_relay:
driver = smtp
port = 587
hosts_require_auth = <; $host_address
hosts_require_tls = <; $host_address

/etc/exim.authenticators.post.conf:

auth_login:
driver = plaintext
public_name = LOGIN
client_send = : [email protected] : uqDLHowJpcFbRoBK


I also recommend you change the password for your [email protected] since you posted your config with the password still there. I have not testing these settings, but from what I see, reverting your exim.conf to stock (with the exception of uncommenting out the clamav lines) and adding the above settings to the specified files, should allow you to send/receive emails and not allow that hacker to send emails as though your server were an open relay. Also note, that you should not set server_set_id to the to your auth_relay. That potentially too could be your problem, that is what tells exim what to set $authenticated_id to.

so i used a default exim.conf added everything you said in the 3 other configs with the correct password (new one)
and it continues
(restarted exim 2 times)
2018-03-13 16:49:42 plain authenticator failed for host-238-net-99-160-119.mobilinkinfinity.net.pk (mail.opelmanta.be) [119.160.99.238]: 535 Incorrect authentication data ([email protected])
2018-03-13 16:49:52 login authenticator failed for (User) [181.215.195.231]: 535 Incorrect authentication data ([email protected])
2018-03-13 16:49:56 1evmBX-0002zp-69 <= [email protected] H=host-238-net-99-160-119.mobilinkinfinity.net.pk (mail.opelmanta.be) [119.160.99.238] P=esmtpa A=plain:alex S=3935 id=654530110556$dngn3v4t$5y2m57wf$@Chaviva-PC T="" from <[email protected]> for [email protected]
2018-03-13 16:49:56 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1evmBX-0002zp-69
2018-03-13 16:50:02 1evmBX-0002zp-69 => [email protected] <[email protected]> F=<[email protected]> R=transip_email T=auth_relay S=4018 H=vps.transip.email [149.210.149.126] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes A=auth_login C="250 2.0.0 Ok: queued as 400znc4YtDz1gx4G"
2018-03-13 16:50:02 1evmBX-0002zp-69 Completed
2018-03-13 16:50:05 1evmBg-0002zp-8k <= [email protected] H=host-238-net-99-160-119.mobilinkinfinity.net.pk (mail.opelmanta.be) [119.160.99.238] P=esmtpa A=plain:alex S=3904 id=052803127513$4dbon99f$tehhwpy1$@Porter-PC T="" from <[email protected]> for [email protected]
2018-03-13 16:50:05 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1evmBg-0002zp-8k
2018-03-13 16:50:07 1evmBg-0002zp-8k => [email protected] F=<[email protected]> R=transip_email T=auth_relay S=3987 H=vps.transip.email [149.210.149.126] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes A=auth_login C="250 2.0.0 Ok: queued as 400znp5p9Cz1ynW"
2018-03-13 16:50:07 1evmBg-0002zp-8k Completed
2018-03-13 16:50:10 1evmBm-0003cj-20 <= <> H=outbound2.mail.transip.nl [149.210.149.73] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=7594 [email protected] T="Undelivered Mail Returned to Sender" from <> for [email protected]
 
gonne change the passwords again and maybe give it some more time :)
maybe was in still queue :)
it looks like nothing at the moment just the ones i posted maybe could be in some queue

but i will not say to soon that its over.. :)
i think the not set server_set_id could the the biggest thing together with no_more
if i don't have alot spammers anymore is it safe to stop some country bans? to let iptables be less overloaded? :)
i'm banning them if they more do than 1 error 535
i think that could be fine enough?
[root@gsi ~]# iptables -L -n |wc -l
104318
:)
 
Last edited:
You can check the queue to see if they were existing messages.
Code:
2018-03-13 16:49:52 login authenticator failed for (User) [181.215.195.231]: 535 Incorrect authentication data ([email protected])
2018-03-13 16:49:56 1evmBX-0002zp-69 <= [email protected] H=host-238-net-99-160-119.mobilinkinfinity.net.pk (mail.opelmanta.be) [119.160.99.238] P=esmtpa [COLOR="#FF0000"]A=plain:alex[/COLOR]
Based on the A=plain:alex I see in the log file above, that tells me they were authenticated using the plain authenticator and the username alex. Try changing the password for a user name alex. Since it isn't a full email address, it should be a unix account.
 
You can check the queue to see if they were existing messages.
Code:
2018-03-13 16:49:52 login authenticator failed for (User) [181.215.195.231]: 535 Incorrect authentication data ([email protected])
2018-03-13 16:49:56 1evmBX-0002zp-69 <= [email protected] H=host-238-net-99-160-119.mobilinkinfinity.net.pk (mail.opelmanta.be) [119.160.99.238] P=esmtpa [COLOR="#FF0000"]A=plain:alex[/COLOR]
Based on the A=plain:alex I see in the log file above, that tells me they were authenticated using the plain authenticator and the username alex. Try changing the password for a user name alex. Since it isn't a full email address, it should be a unix account.

hm nice could be that i will change the user in directadmin & in ssh that should be enough i guess
gonne set them to the same pass but i guess changing in directadmin should be enough
Thanks for the thinking it was kind of stupid of me that i did not saw that the alex and not alex@ but strange they use [email protected] as sending adres :)
pass changed ;-)
 
Last edited:
i'm greping now on:
[root@gsi ~]# tail -F /var/log/exim/mainlog |grep A=plain:alex
and will see if it stops :) Many thanks everybody and as specialy toml
for the effort and everything !!
i hope everybody that has a similar problem could find the solution faster than i had it ;-) grz alex
 
Back
Top