On Mon, Sep 30, 2002 at 01:16:14PM +0200, Philip Paeps wrote:
>
> Hi guys -
>
> I'm getting fed up with all the spam reaching my system. I use spamassassin,
> which makes the spam somewhat bearable, but I'd like to be even more effective
> by just bouncing things that are probably spam.
>
> I had a look into the sample_smtpd.cf file at all the restrictions, but I'm a
> bit confuzzled by them all. I assume that order in the restrictions is
> important, and that it might be best not to combine some of them if I want to
> receive any mail at all. Currently, I've got the following:
>
> # JUNK MAIL CONTROLS
> #
> # The controls listed here are only a very small subset. See the file
> # sample-smtpd.cf for an elaborate list of anti-UCE controls.
>
> maps_rbl_domains = socks.relays.osirusoft.com spews.relays.osirusoft.com
> relays.ordb.org blackholes.mail-abuse.org relays.mail-abuse.org

  Don't use spews! They're hopeless - they put huge IP blocks in there
and never remove them, even after they are reallocated to someone
totally different.

  Also, all the mail-abuse.org lists have been subscribers-only for
some time. Worth the price, IMHO, but it makes it more trouble to use
them.

  Here is what I would recommend for a first-cut free RBL list:
  relays.ordb.org proxies.monkeys.com (Hi Ron!)

  These will block known open relays, and open proxy servers. In
practice that's where a tremendous proportion of your incoming spam
will come from. Both these lists are responsible about testing IPs
before they are added to the list, don't create problems for other
networks by scanning at random, and are responsible about providing a
reasonable way for sites ask to be taken off the list after verifying
that the problem is repaired. I'm not sure what to recommend as the
best "spamhaus" RBL list (major blatant spam sources, vs. abused
relays/proxies) or as a dialup IP list.

  We are not using either of these for RBL testing here, we are only
using the MAPS RBL+, but we test them in our procmail filtering and are
seriously considering them as MTA-level RBL candidates.

 
> smtpd_helo_required = yes

  Yes, you should absolutely have this.

> smtpd_helo_restrictions = reject_invalid_hostname reject_non_fqdn_hostname
> reject_maps_rbl
 
  I've found most of the smtpd_helo_restrictions reject too much valid
mail from incompletely configured (but working) mail servers. For
instance, I see a fair number of valid non-relaying Linux servers which
issue a HELO as localhost.localdomain (sic.) This will fail those
tests. Similar problems with a lot of Windows machines. If you do use
these tests, you should put them after permit_mynetworks. Or you can
decide to reject some valid mail from such hosts; your call.

> smtpd_sender_restrictions = reject_invalid_hostname reject_non_fqdn_hostname
> reject_non_fqdn_sender reject_maps_rbl

  reject_non_fqdn_sender is good.

  reject_invalid_hostname and reject_non_fqdn_hostname are commented on
above - they do the same thing here and so are redundant. (They check
the HELO parameter, not the sender address's hostname.)

  A good way to proceed is to add restrictions one by one, preceding
each with warn_if_reject, and look at what gets logged as warnings in
your log for a few days. If it looks like you wouldn't be rejecting
things you want to accept, then remove the warn_if_reject so it becomes
active, and try adding another as a warning.

  -- Clifton

-- 
    Clifton Royston  --  LavaNet Systems Architect --  cliftonrlava.net
"What do we need to make our world come alive?  
   What does it take to make us sing?
 While we're waiting for the next one to arrive..." - Sisters of Mercy
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]