Roderick A. Anderson wrote:
mouss wrote:
Roderick A. Anderson wrote:
I'm implementing greylisting on CentOS 5 systems.
These are spools for the actual mailserver/mailbox systems.
Currently we have:
smtpd_recipient_restrictions =
reject_unauth_pipelining,
useless.
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unknown_sender_domain,
reject_unlisted_recipient,
permit_mynetworks,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client cbl.abuseat.org,
permit
All the install documents I've found say to put the
check_policy_service after reject_unauth_destination but looking at
this I wonder if it should go further down on the list. Possibly
after reject_invalid_hostname or reject_non_fqdn_hostname.
if it returns "defer_if_permit", put it at last (after
reject_rbl_client ...).
if it returns "defer", put it just before the first reject_rbl_client.
if in doubt, put it at last.
PS. when I say put it at last, I mean before the (useless) "permit".
In fact how does the above listing look? It has been working for
years but maybe there is a better order or some additional checks
that could be done.
depends on what you want. the following is somewhat similar to your
setup:
smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
#permit_sasl_authenticated
reject_unauth_destination
reject_unlisted_recipient
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_sender_domain
reject_rbl_client zen.spamhaus.org
#check_policy_service ...
the differences with your setup are left as an excercice;-p
Thanks ... I think! Well actually it was a good exercise. We started
upgrading all the systems OS' which gave us /more/ current version of
Postfix and just copied main.cf over and everything seemed to work fine.
Two questions -- the second sort-of a double question.
1) Why would we want/need permit_sasl_authenticated? This is an inbound
spool/relay. Should only forward to those domains in transport maps and
mail for accounts in relay_recipient maps.
you only need permit_sasl_authenticated if you want to allow users to
relay via your server after they are authenticated.
if this is an "MX only" server, then you don't need that.
2) Why only the one rbl_client? (I see it is a commercial service) And
the second part is where do I find a list of valid/good RBL
services/providers. My search using Google didn't seem quite right.
zen is the safest and most effective. it is free up to some limit. if
you get too much mail, you can pay for a feed.
if you get too much mail, most lists will block you after you knock them
too heavily. They generally prefer rsync or equivalent if you need more
than N queries.
Note that cbl is included in xbl which is included in zen. cbl
maintainers prefer that you use zen.
?) One last one to sneak in. Does it make sense to have a bunch of
reject_rbl_client entires? I saw one article that had 10. I know it
will cost more to do more so are there any indications that it is worth
the expense?
the only way to know is to test. you can test by using warn_if_reject.
then parse your logs and see which lists are safe for you, and which
combination is effective (if a list blocks 3 spam sources among 1000,
then it's probably not worth the pain).
here (and other list members have reported similar results), zen catches
a lot of spam sources, and once it is used, other DNSBLs don't catch
much. (of course, if you don't use zen, or if you use zen after other
DNSBLs, then you'll get other results).
