l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2008 Jun 30 12:45

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] postgrey is dangerous?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] postgrey is dangerous?

On Sun, Jun 29, 2008 at 04:17:38PM -0700, Tony Cratz wrote:
> Larry Ozeran wrote:
> > Hi,
> > 
> > I have used a web host based in North Carolina for many years. I recently upgraded from a shared server to a dedicated server and I was hoping to be able to install some SPAM fighting tools. The SPAM software they provide is limited to white listing and black listing and I am now receiving huge volumes of it. I am a part time programmer, not familiar with networks or email servers, but I am tired of huge volumes of SPAM. I reviewed various sites and felt that installing postgrey might give me substantial SPAM reduction with minimal challenges. When I asked my host about installing it, I was told:
> > "After further investigation I was able to verify that the request was denied.
> > It was specified that this software would be unsafe to run on the server environments run within our network.
> > This is per our Systems Administrators."
> > 
> > After going around with them twice, I don't have what I feel is an adequate answer. Any thoughts on why someone might think that postgrey is "unsafe"? Better yet, any strategies for countering this thinking?
> > 
> >  = = system info - yes the versions are old, but that's not my host's excuse for the denial and they can be updated now that I am on a dedicated server
> > Operating System:  	Redhat Linux Kernel Version: 	2.4.26
> > Apache/PHP Version: 	Apache/1.3.34 (Unix) filter/1.0 PHP/4.4.4
> > Perl Version: 	v5.6.0
> > MySQL Version: 	3.23.33
> > Send Mail Version: 	8.12.10
> > 
> > Thanks for any suggestions or clarifications.
> 	I did a could of quick searches and found a couple of things.
> 	There was a security DoS (Denial of Service) issue in the 2006
> 	time frame using Postgray 1.21. On Debian systems there was a
> 	patch which fixed the problem (I did not see any patch for
> 	Red Hat).
> 	The current version of Postgrey is 1.31 with a timestamp of
> 	9/2007.
> 	With the above it would be a good chance the DoS issue has
> 	been solved.
> 	Now lets quickly take a look at how Postgrey works. If the
> 	message the SMTP server receive is the first connection of
> 	a message it is TEMPFAIL rejected (meaning it must be attempted
> 	to send again before the message is accepted).
> 	Now one might ask why do this? At one time some of the spammers
> 	would only attempt to send a message once and if they received
> 	a TEMPFAIL they would drop the message, thus reducing the
> 	amount of SPAM a site might received from a spammer.
> 	PLEASE NOTE: This was before the use of zombie networks. Now
> 	they have the zombies send the message and they don't care if
> 	the zombies have a TEMPFAIL as the message is not sitting on
> 	the spammer machine but maybe on the zombie system but more
> 	likely it is setting on the ISP of the witless user of the
> 	zombie system.
> 	So the bottom line is, using Postgrey now is just a waste of
> 	computer resources and time. As fir it currently being a
> 	security issue, I can't find anything to suggest this is
> 	still true. But your ISP may be using it as an excuse to
> 	not waste their time setting it up, or they may not be using
> 	Postfix (which is required for Postgrey). They could be using
> 	Sendmail, Qmail or Exim.
> 	Is there better solutions? I know a lot of people are using
> 	mimedefang + SpamAssassin + ClamAV to reduce the amount of
> 	SPAM and viruses. Can you stop all SPAM using these methods?
> 	NO. Can you reduce the SPAM yes. Are there other things which
> 	can be done also? Yes you can use DNS blacklist such as
> 	Spamhaus and SpamCop. Again these only help to reduce the
> 	SPAM.
> 	The only way to possible stop SPAM is to rewrite all of the
> 	RFC dealing with mail and require each clients to certify who
> 	they are so the true path can not be hidden and the spammers
> 	could be trace. Note: This really would not fully solve the
> 	problem but would allow the message to be traced back to the
> 	zombie system a lot faster. But zombie networks could still be
> 	used. It would just require a new one to be set-up which would
> 	take time. I also make note of a news article from last year
> 	(sorry I don't have the link any more) where a System installer
> 	who worked out of the US setting up systems for the customers
> 	of the company he worked for (kind of like the Geek Squad of
> 	Best Buy) where he installed the software to turn the systems
> 	into zombie servers.

I am using sa-exim which supports greylisting. I also received about 500
spams where the spammer used guestbooks and e-card sites, feedback
forms, and whatever they could post to to send me the spam. I am willing
to be they used Google to harvest the sites with these services, put
together some bots to activate the guestbooks, e-cards, feedback form
sites that send replies to the client using the page, and then activated
them all at once. I still have the spams, so I can harvest the IPs of
the relaying servers and perhaps just block their servers. 

One way to completely block SPAM is to use TLS / SSL and allow only
authenticated mail servers to relay into your mail server. 

Brian Lavender
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!