You *COULD* add the IP of the website to your SECURITY > WHITELIST or alternately the SECURITY > ANTISPAM ADMINISTRATION > BYPASS GATEWAYS. This would prevent it from getting blocked by your Abuse Detection Rules.

 

*HOWEVER* it sounds like the Abuse Detection is doing it's job, which is ultimately what you want. It is protecting the reputation of your Outgoing Mail Server by blocking abuse from rogue scripts trying to send through it. If the website is continuously being infected by uploaded scripts I would resolve it by making sure that their web app is using SMTP Authentication and then set the php.ini (or user.ini depending on your server's PHP configuration) to have a line that reads as such:

[PHP]
[mail function]

sendmail_from = unauthorized@mydomainname.com

 

I would then add the IP Address to my Whitelist and then go to SECURITY > ADVANCED SETTINGS > SMTP Blocking and add an entry for unauthorized@mydomainname.com.

That way, their PHP web application can send email just fine without worry because it is using SMTP Authentication and the IP Address will never be blocked because it Whitelisted, however any rogue scripts that are uploaded or created through vulnerabilities will not be able to abuse the PHP sendmail function routing through your Smartermail Server because they will automatically be blocked based on the FROM: address of unauthorized@.

You want to be VERY careful about whitelisting any server's IP address:  especially a server which is running PHP!

 

I share this thought because about four years ago I was contracted to resolve a spamming issue on a server in Stockholm Sweden.  The ISP was running both SmarterMail and IIS - with about 160 websites running, and many of them were running PHP.  The owner of the small ISP was extremely careful with his security and passwords, and there were multiple levels of encryption and VPNs to connect - overall excellent security.

 

There were no SMTP bypasses.  There were no white listed IP addresses in SmarterMail.

 

We used every available tool to monitor the networks - working for almost 3 days, to vet the source of the more than 500,000 spam messages per hour which were being generated - and none of them were SMTP authenticated, with everything going through SmarterMail.  The customer was running an early version of SmarterMail 7.X, so the log reporting was not nearly as good as it is in SmarterMail 14.X.  That meant we were limited to Microsoft logs, IIS logs (which were mostly useless in this case), and monitoring - using every available tool and resource then available.

Long story short:  The ISP owner's daughter had a hair salon.  It had been built in PHP, and, with the exception of new hours, had not really been updated in several years.

It turns out that the owner's daughter's website was the weak link, but, because he had some large business sites hosted on the server, he was unwilling to allow me to just turn off IIS to see if that stopped the problems.

 

In sheer frustration, I finally disabled IIS and the spam stopped - cold.

 

I then disabled all of the websites, individually, and restarted IIS, and there was still no spam.

 

So, I enabled the websites, one at a time, and, withing seconds of re-enabling his daughter's hair salon website, which was written in PHP, the spam started flowing again.

 

Now I had a clue to work with and we were able to find out where someone had gone into the actual SmarterMail configuration files and white listed all of the websites using a text editor.  These edits were not showing up in the SmarterMail interface, so there was no reason to think anything was white listed in SmarterMail.

 

We found the edit, removed the white listed sites, and had his web  development team redo the e-mail sending capabilities of each of the sites to enforce full SMTP authentication.

Problem resolved.  Spam ended, but not before close to 10 million spam messages had attempted to flow through the ISPs SmarterMail system.

While whitelisting may be tempting -- it's a "quick and dirty fix," it's never a good idea.  The better solution is to re-code the website(s) in question, and run proper SMTP authentication on all contact forms, newsletter sign up sheets.

There's another reason to use proper SMTP authentication, too:  Many large ISPs, taking the lead of YAHOO!, have begun to look for an indication in the e-mail header that indicates that the message was properly SMTP authenticated.
 

SmarterMail 14.X provides this vehicle in the form of an "X-SmarterMail-Authenticated-As" message header record.

 

In the example below, with some of the data obfuscated to protect the identity of the server from which it was sent, you can see how that "X-SmarterMail-Authenticated-As" is inserted in the header.

 

Hi,

I would not prefer to whitelist any IP, as the IP getting blocked is shared and used by many sites incase if i whitelist it and any other type of spam or similar to this from other domain can create havoc

 

I need solution to block mails through phpmailer for specific domain, i was able to identify one unknown script on that php site which i deleted and mails stopped, but after a day again this kind of script comes in some other folder of the site, so there is issus with the site which is getting investigated but i need to find solution to stop such mails if occurs in future with some other domain etc.

 

Due to volume of relay this script creates it immediately triggers DDOS and all web forms gets stuck as they get server busy error 421

 

should SMTP AUTHENTICATION BYPASS must have 127.0.0.1 or mx IP  ? if i remove 127.0.0.1 this then does it mean all webforms where smtp is not authenticated will be stopped, if so then this might help and force customers to recode their webforms.

 

In smtp log it says IP IN AUTH BYPASS

 

Thanks

SMTP Authentication Bypass should not have any entries unless they are absolutely, positively necessary. It sounds like you are running Smartermail on the same server as your Web Server? In such a case you do not need 127.0.0.1 as that is allowing *ALL* mail received from that local machine to be sent by Smartermail without authentication. Removing that IP would require all mail sent from your hosted websites (whether web forms or phpmailer scripts, whatever) to use SMTP Authentication. Once removed from SMTP Authentication Bypass you should be able to safely add 127.0.0.1 to your Whitelist to avoid it blocking itself when a site keeps trying to send email without SMTP Authentication (although note that Whitelisting will prevent you from doing Outgoing SMTP Antispam Checking on those emails).

Have removed all 127.0.0.1 from smtp authentication bypass so now everyone by default has to authenticate web based forms, is it safe to add MX IP to whitelist now so that when ddos triggered it doesnt add own IP to SMTP block