Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm looking to figure out some kind of way to create a spam tarpit on my server. I get tons of spam daily and I'd like to start fighting back instead of just taking it all and making myself do the work of deleting it. For clarification, what I want to do is accept an incoming connection on port 25 for sending me an email (I don't relay), scan the email in real-time for spam, flag it as spam, and then put a delay in closing the connection and/or keeping the connection open for a prolonged period of time if the email is flagged as spam. If that can't be accomplished with my current setup, I would consider an alternative solution of doing all of the above, but instead of tarpitting in real-time I would store the sender's IP in a greylist and tarpit all their future connections in real-time.
Here's my configuration: Redhat Fedora Core 3, sendmail MTA, SpamAssassin w/ procmailrc configured to flag spam.
I know there exists a script called "SpamCannibal" that will probably do the job I'm looking for, but I believe it requires that port 25 connections come directly through it. The solution I'm looking for would require very minimal impact to my current configuration.
I already have procmailrc to scan an email with spamd (SpamAssassin, not the other spamd), flag it above a certain threshold, and then move that mail into the "spam" user account. I don't like IMAP, so I actually created a separate "spam" account/email and that's where it all goes to.
Anyway, I'm aware of a solution using "pf" for openBSD, but I can't find a similar program for Redhat flavors. Anyone have any suggestions for how I can make this happen without changing my setup too much? I really don't want to get rid of sendmail or SpamAssassin because I like the way I have them setup, and I don't want to fix something unless it's broken.
I'm using postfix and postgrey as my first blockade for spam. Spam are mostly sent through spambots and greylisting eradicates not less than 80% of spam. Spambots usually does not retry after greylisting (artificial RCPT TO time out) since these are just worms installed remotely on many computer zombies directed through Botnets. With greylisting, most of spam are already prevented on entering your server and you will be happy on deleting only very few of them - those that are sent through legitimate MTA only.
My installation before without postgrey is bringing not less than 50 spam and virus mails in its quarantine daily, but after postgrey was added, it's reduced greatly to less than 10 daily.
Another benefit is that it has prevented as well on clogging my system with undeliverable spam mails scheduled to be sent back to spammers short-lived domains to give them warning and lessons through amavisd-new.
Thanks again very much! I loaded up something called relaydelay from puremagic.com and it works great so far!
Of course I had some issues with Sendmail's Milter. I figured out that my Sendmail was configured with Milter, but I didn't actually have the Sendmail::Mailter perl module installed, which is different than compiling Sendmail w/ Milter I learned, even after I downloaded the newest Sendmail and recompiled it. Anyway finding Sendmail::Milter was the hardest part, after that everything worked pretty much like magic.
My only complaint is that there's not much help for setting up relaydelay, so you need to have intermediate admin experience. Also, it seems as though it takes most mail servers quite awhile to retry once they get the tempfail message, so that adds significant delay into my received messages. I guess I can live with it though for the sake of helping stop spam.
Relaydelay is another greylisting implementation maybe.
Postgrey is an implementation of greylisting for postfix developed by another. Postfix has its native implementation of greylisting but I preffered using postgrey.
The RCPT TO delay with postgrey is defaulted to 500 seconds (5 mins) and it is configurable. This default so far is efficient enough and I never changed it since normally MTAs retries within 10-11 minutes per my observation and the delay is neglegible.
But the relay delay (greylisting) isn't permanent with postgrey because it has embedded database (BerkeleyDB) that stores MTAs that she already trusted. This is called autowhitelisting. This happens without the intervention of the administrator by auto marking those legitimate MTAs that has already succeeded at least 5 email deliveries (at least one per hour) after the end of the greylisting period. The frequent an MTA delivers mails to your MTA after its autowhitelisting, the longer it will be whitelisted and no more greylisting (relay delay) will happen to her.