Stan,
Thanks for the quick reply. All I can say is WOW.
I did poke around on this CentOS install and am not seeing a config file
like you have but perhaps this is it:
[r...@hosting1 ~]# find / -name postgrey
/usr/sbin/postgrey
/etc/rc.d/init.d/postgrey
/var/spool/postfix/postgrey
________________________________________________________
[r...@hosting1 ~]# cat /etc/rc.d/init.d/postgrey
#!/bin/sh
#
# chkconfig: - 79 31
# description: Postfix Greylisting Policy Server
#
# processname: postgrey
#
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
prog=postgrey
postgrey=/usr/sbin/$prog
DBPATH=/var/spool/postfix/postgrey
SOCKET=$DBPATH/socket
OPTIONS="--unix=$SOCKET"
# Source an auxiliary options file if we have one, and pick up OPTIONS,
if [ -r /etc/sysconfig/$prog ]; then
. /etc/sysconfig/$prog
fi
[ -x $postgrey -a -d $DBPATH ] || exit 0
RETVAL=0
start() {
echo -n $"Starting $prog: "
daemon $postgrey -d $OPTIONS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
}
stop() {
echo -n $"Stopping $prog: "
killproc $postgrey
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
}
restart() {
stop
start
}
reload() {
echo -n $"Reloading $prog: "
killproc $postgrey -HUP
RETVAL=$?
echo
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reload)
reload
;;
condrestart)
[ -f /var/lock/subsys/$prog ] && restart
;;
status)
status $postgrey
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart|reload|status}"
exit 1
esac
exit $RETVAL
________________________________________________________
I am assuming from your conf file you have:
> POSTGREY_OPTS="--inet=127.0.0.1:60000"
>From the options I see, I could put that into the startup file above by
changing:
OPTIONS="--unix=$SOCKET"
To
OPTIONS="--inet=127.0.0.1:60000"
My question now lies in do I need to add any any additional config to
master.cf file to take advantage of this service?
Thanks
Steffan
---------------------------------------------------------------
T E L 6 0 2 . 7 9 3 . 0 0 1 4 | F A X 6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Cline
stef...@execuchoice.net Phoenix, Az
http://www.ExecuChoice.net USA
AIM : SteffanC ICQ : 57234309
YAHOO : Steffan_Cline MSN : stef...@hldns.com
GOOGLE: Steffan.Cline Lasso Partner Alliance Member
---------------------------------------------------------------
> From: Stan Hoeppner <s...@hardwarefreak.com>
> Date: Tue, 22 Jun 2010 23:34:09 -0500
> To: <postfix-users@postfix.org>
> Subject: Re: Spam filtering
>
> Steffan A. Cline put forth on 6/22/2010 8:01 PM:
>
>> It's a long post. Sorry.
>
> Yeah, it was long, and probably overly ambitious for a single thread topic.
> Instead of addressing your questions about individual main.cf parameter
> settings and policy services, I'm going to make a few suggestions which should
> give you a good start on rejecting most spam.
>
> 1. Keep your configuration as streamlined and simple as possible
> 2. Put all your restrictions under smtpd_recipient_restrictions
> 3. Use the regexp table I'm providing at the link far below
> 4. Use dnsbl queries selectively (why they're at the bottom)
> 5. Use only selective greylisting with postgrey (why it's last)
>
> Here's a sample smtpd_recipient_restrictions section you could start with,
> good with IIRC Postfix 2.3 and later. But first:
>
> smtpd_delay_reject = yes (unneeded as it's the default behavior)
> smtpd_helo_required = yes (you need this)
>
> smtpd_recipient_restrictions =
> permit_mynetworks
> reject_unauth_destination
> permit_sasl_authenticated
> reject_unknown_reverse_client_hostname
> reject_non_fqdn_sender
> reject_non_fqdn_helo_hostname
> reject_invalid_helo_hostname
> reject_unknown_helo_hostname
> reject_unlisted_recipient
> check_client_access regexp:/etc/postfix/fqrdns.regexp
> reject_rbl_client zen.spamhaus.org
> reject_rhsbl_client dbl.spamhaus.org
> reject_rhsbl_sender dbl.spamhaus.org
> reject_rhsbl_helo dbl.spamhaus.org
> check_policy_service inet:127.0.0.1:60000
>
> This should be all you need for now. You will improve this configuration over
> time.
>
> It appears in your example that you're querying postgrey twice, once via UNIX
> socket and once via inet. Pick one method, don't use both. I use the inet
> method (last line in main.cf above). You will need to configure that one
> method per the postgrey instructions.
>
> The Postgrey daemon config file on Debian is at the following location. On
> CentOS it may be located in a different directory. I don't use any Red Hat
> products so I'm unsure. You'll have to find it.
>
> cat /etc/default/postgrey
> # postgrey startup options, created for Debian
> # (c)2004 Adrian von Bidder <avbid...@fortytwo.ch>
> # Distribute and/or modify at will.
>
> # you may want to set
> # --delay=N how long to greylist, seconds (default: 300)
> # --max-age=N delete old entries after N days (default: 35)
> # see also the postgrey(8) manpage
>
> POSTGREY_OPTS="--inet=127.0.0.1:60000"
>
> # the --greylist-text commandline argument can not be easily passed through
> # POSTGREY_OPTS when it contains spaces. So, insert your text here:
> #POSTGREY_TEXT="Your customized rejection message here"
>
> If you run into problems, "man 8 postgrey"
>
>
> SPF and DKIM checks are pretty much useless for killing spam. You will
> already kill bot spam with other methods. Many snowshoe spammers are keen on
> using SPF records and to a lesser extent DKIM sigs. There really aren't any
> other large classes of spammers than bot and snowshoe, so again, trying to
> kill spam with SPF and DKIM checks is mostly an exercise in futility, and it
> adds unneeded complexity to your configuration. This has been discussed ad
> naseam on many spam fighting lists over the years.
>
> Regarding helo checks, it seems you're merely wanting to save effort expended
> on a previous mail server platform on which they worked well. Wrong logic.
> Helo checks won't kill much more spam than other checks, and the helo checks
> above are typically sufficient without getting into table checks against them.
> Don't worry about dragging the old helo stuff over to Postfix, as it will be
> wasted effort for the most part. Maybe keep them around for a rainy day down
> the road and convert them over _IF_ you find you _need_ them.
>
> Again, think "streamline". Try to keep the configuration _simple_. The more
> complicated you make main.cf now the harder to troubleshoot is becomes later.
> Notice how short and simple my restriction list is? And don't think for a
> minute I created that overnight. I've been using Postfix since 2005 and have
> been refining it for 5 years. It became really streamlines after I took the
> advice of members of this list. Noel, mouss, and many others have helped me
> tremendously in streamlining my Postfix config, along with the excellent
> documentation, which can at times be a bit intimidating to the novice.
>
> This magic regexp table will kill a lot of bot and other spam coming from
> various ISPs' mostly dynamic space and will do it quicker than a dnsbl lookup.
> Another advantage is that it cuts down on your lookup queries, so if you're
> on that 300k Spamhaus borderline limit between paid and free service, this
> should drop those queries to the point you could likely use the free service.
> Even if you're not borderline, it's always better to kill spam with local
> filters before querying any outside service, dnsbl or otherwise.
>
> Download this http://www.hardwarefreak.com/fqrdns.regexp and save it in
> /etc/postfix/fqrdns.regexp as root. Make sure the permissions are the same as
> your other lookup tables.
>
>
> Hope this gives you a good start with Postfix spam fighting. Please continue
> to ask questions if you need more pointers. Also, make use of the extensive
> documentation and how to's on the Postfix website:
>
> http://www.postfix.org/documentation.html
> http://www.postfix.org/docs.html
>
> --
> Stan
>
