Server bruteforcing own external ip?

[Richard G]

Our brute-force monitor with block feature, blocked our external server ip 2 times.

This is what the exim logs says:

2012-07-22 19:32:55 plain authenticator failed for ns1.mycompany.nl (userdomain.nl) [217.23.xxx.xxx]: 535 Incorrect authentication data ([email protected])

Now I know this user has a webshop and on my advice, he does not use the php mail function but the smtp function with authentication.

We moved the server and until that move 2 days ago, everything worked fine.

The user check his password and normal mail is working, only the webshop using smtp mail is giving this problem.

Am I correct in my assumption? Or can there be other causes?

 

[Richard G]

I've found that this might be a bug or a server problem.
This works fine as not a couple of hunred emails are send at once.

But when a user sends about 4.500 emails, the server can't cope with the authentication anymore and authentication errors will occur even when the username and password etc. are correct.

Just to be sure I changed this to the php mail function again and the problem was gone and still only valid emails went out.

So I'm not sure what is causing it, but it's either Exim or it's the communication between the used software (Prestashop in this case) with authentication active and Exim when sending a lot of emails. And this results in authentication errors where in fact there aren't any false authentications.

 

[DirectAdmin Support]

Hello,

Hard to say. It is possible that the perl implementation of the authentication isn't able to keep up..
It may also be a message limit in exim, but we'd probably be seeing an error with regards to such a limit if that were the case.

A few options:
1) see if you can rate limit the email sends slightly. Spacing it out may allow exim (or the exim.pl) to keep up.

2) Try adding your IP to the pop_hosts line, so that no smtp auth is needed for that IP, eg:

hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : [b]1.2.3.4[/b]

3) If you are farmilar with perl, a manual check of the user/pass combo you're using for the mass send could be done, before the actual passwd file check.
Edit the /etc/exim.pl, and in the very first function "sub smtpauth", right before "if ($username =~ /\@/)", add something like:[code]if ($username eq "[b]yourusername[/b] && $password eq "[b]yourpassword[/b]")
{
        return "yes";
}

so that no file lookups are needed.

Of course, using option #3 would mean your password is in the file.. in which case you'd likely want to try and chmod the /etc/exim.pl to 600, chown mail:mail... however, I'm not sure if everything will work with those permissions.

John

 

[zEitEr]

Isn't it needed to be 700, not 600?

/etc/exim.pl to 600, chown mail:mail...

 

[Arieh]

In case you send many e-mails at one php request (e.g. newsletter, mass mail etc..), you could also send multiple e-mails over one smtp authentication. So instead of creating a new socket for each e-mail and having a authentication at each request, you can send multiple mails over just one. With Exim, this also gives the advantage that all e-mails after then 10th (default) will be queued low priority so other e-mail traffic isn't bothered as much.

 

[Richard G]

Thank you all for the comments and advise.

@Da Support:

2) Try adding your IP to the pop_hosts line, so that no smtp auth is needed for that IP, eg:

hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : 1.2.3.4[/quote]
I could do this, but isn't that almost the same as using php mail then? No auth is needed for that either. And it's not for an email client but for webshop software present on the server, which is sending mail to a lot of clients, or has a build in newsletter function.

@Arieh: I know of this possibility, but it's a piece of webshop software doing this (Prestashop), so I think I will contact the makers and ask them to adjust the smtp authentication as suggested by you.