Help - Search - Members - Calendar
Full Version: SpamControl or Spam Rules
The Planet Forums > Control Panels > Plesk
HaiFred
Hi,

Does anyone knows if it's ok to install SpamControl on a Plesk server :
http://www.fehcom.de/qmail/qmail.html

Has anyone tried Spam Rules, another anti-spam utility :
http://isle.wumpus.org/cgi-bin/pikie?SpamRule

Could you please let me know if it's ok to install with Plesk, if you have tries to install it ?

Thanks
b00gie
I dont use any SPAM protection software.


1) If you have an internal spammer, terminate them

2) In PSA under "server" edit the mail settings. Under Relaying choose "require authorization" check POP3, do not check SMTP. Set the timeout. Mine is 30 minutes.


This will require anyone trying to send mail through your server to first authenticate before they are allowed to send mail. The timeout is how long they have before the authentication expires.


In English... You must check your mail before you can send mail. After doing so you will have "X" minutes to send mail, before you must check mail again.
HaiFred
Hi,

Thanks but I already know all this.

The problem is when the server relays spam without my authorisation : no formmail, and no SMTP authorisation, but still a lot of spam said to be sent "from the network".

I know which IP send it, but those IPs don't authenticate first, but can still send mail through SMTP. I don't know how !!!
I can block the IPs using iptables.

Thanks
Rich2k
I just use the spamcop blacklist as a MAPS server.
NightHawk
QUOTE
Originally posted by HaiFred
Hi,

Thanks but I already know all this.

The problem is when the server relays spam without my authorisation : no formmail, and no SMTP authorisation, but still a lot of spam said to be sent "from the network".

I know which IP send it, but those IPs don't authenticate first, but can still send mail through SMTP. I don't know how !!!
I can block the IPs using iptables.

Thanks


Hrm...you have some problems with your setup then....if your server is setup as open relay....

Suggest that instead of adding in spam filters..you first close your relay...make sure that your email settings for the server are set to either , closed, pop, or smtp authentication....then test your relay...make sure it is not an open relay....if that passes..and they are still getting email sent out via your box...watch your logs closely....there is probably a script of some sort that is allowing it....be it a forum, a guestbook, a auction script...a formmail..or a formmail clone....etc....you just have to find it...

just installing anti-spam software wont' really help you...as they will still be able to send anything they want....they would just have to then avoid anything that the anti-spam software would catch.....(which still leaves them the possibility of using your server for alot of email.)
HaiFred
I understand what you're saying, but my server is not an open relay, I've tested it on open relay test sites, and it's ok.

Furthermore, my own customers, using this server, can't send emails, and I cannot find the IPs anywere else, so I do understand that another script can send emails, but if it was the case, then I would see the sender's IP in an access_log and I would see the user ID in the header of the email, but I do see the IP in the header of the email, and not in an access_log.

Now, my customers don't even receive any emails, and I don't know why either !!! I'll create a ticket.

Thanks
AvaMail
I have same problem...
Ho to correct it?

2HaiFred do you resolwed it?
HaiFred
Well, the problem was that I got an open-relay because I didn't calculate the network part of an IP I allowed permanently, properly.

I allowed an IP permanently in the White list, but instead of XX.XX.XX.XX/32, I added XX.XX.XX.XX/1, which allowed all IP addresses within this range.

I solved the problem now, but I got local customers who found out a way to send emails through a script in the HTTP. The customer seems to have a script that sends emails from it directly to the SMTP port instead of using sendmail, so I have no header and no way to find out who he is because he's sending it from the network, my logs say.

If you have any solution about this, please let me know.

Thanks
NightHawk
QUOTE
Originally posted by HaiFred
Well, the problem was that I got an open-relay because I didn't calculate the network part of an IP I allowed permanently, properly.

I allowed an IP permanently in the White list, but instead of XX.XX.XX.XX/32, I added XX.XX.XX.XX/1, which allowed all IP addresses within this range.

I solved the problem now, but I got local customers who found out a way to send emails through a script in the HTTP. The customer seems to have a script that sends emails from it directly to the SMTP port instead of using sendmail, so I have no header and no way to find out who he is because he's sending it from the network, my logs say.

If you have any solution about this, please let me know.

Thanks


ahh...yes... that /1 would do it..and would explain why you couldn't register it as an open relay...since you were not testing from that range of ip's.

as for your new issue:
I would suggest watching each domains mail usage...and then when you find the domain that is using alot of email...either go find the script he is using and chmod it 000 or just terminate the account.
HaiFred
Hi,

Thanks for you help.

Actually, the script was a CGI Telnet shell, so the user was using it to access the server, in a telnet-like manner, even though telnet is not accessible on any customer's account.

It took me around 2 hours to find out who this was. I had to create a small script that helped me analise the log files quickly to find who was accessing the server at this time.

The script is actually processing each log file, on each account, and only displays the list of pages/files accessed in the specified time :

cd /home/httpd/vhosts
for i in `ls`
do
echo ----- $i :
#find $i -name "access_log" -exec grep -H "zraw" '{}' ';'
grep "09/Sep/2003:00:01" "$i/logs/access_log.processed"
done


You can use this script, upload it or type it with vi, in the /home/httpd/vhosts directory, chmod it to 755, and type the following command :
./findit >findit.log

findit is the name of the script. It will then create a file called findit.log with all the domains'list and the lines matching the date/time. In the example above, the date/time is set to 09/Sep/2003:00:01 because I knew that the script sent the information to my SMTP server at this time.

Thanks
NightHawk
QUOTE
Originally posted by HaiFred
Hi,

Thanks for you help.

Actually, the script was a CGI Telnet shell, so the user was using it to access the server, in a telnet-like manner, even though telnet is not accessible on any customer's account.

It took me around 2 hours to find out who this was. I had to create a small script that helped me analise the log files quickly to find who was accessing the server at this time.

The script is actually processing each log file, on each account, and only displays the list of pages/files accessed in the specified time :

cd /home/httpd/vhosts
for i in `ls`
do
echo ----- $i :
#find $i -name "access_log" -exec grep -H "zraw" '{}' ';'
grep "09/Sep/2003:00:01" "$i/logs/access_log.processed"
done
 

You can use this script, upload it or type it with vi, in the /home/httpd/vhosts directory, chmod it to 755, and type the following command :
./findit >findit.log  

findit is the name of the script. It will then create a file called findit.log with all the domains'list and the lines matching the date/time. In the example above, the date/time is set to 09/Sep/2003:00:01 because I knew that the script sent the information to my SMTP server at this time.

Thanks


good job...nice use of grep to find what you needed. Suggest you take measures to protect against such a cgi-telnet script being used again. (hit google there are lots of good options...although a good place to start is with your firewall)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.