smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access
hash:/etc/postfix/helo_access,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client relays.ordb.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org ,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.njabl.org,
check_policy_service inet: 127.0.0.1:60000
permit
The check_policy_service inet:127.0.0.1:60000 is for postgrey, a greylisting service. Personally, I hate spam so much, I would rather block my own mother's emails than get spam. The checks above with postgrey have brought me from about 15-20 spam a day to 0 since I have had them in effect. On the otherhand, for the real estate company I work for, some of these options are not acceptable. Postgrey is not acceptable since many of our users expect email to be "instant" I know there is no technical guarantee of this, but they get upset no matter what if their emails take too long. Using postgrey on my own personal server, I make it delay for 5 minutes. Most mail servers will keep trying and I will get the message within 10-15 minutes max. I have had a few times, though, that the mail took 4 or 5 hours before it was tried again. A solution I use for this for my consulting business is to whitelist all of my clients domains. With the real estate company, however, there are too many different users working with too many different and new companies to try and whitelist them all.
I actually do keep the rbls for all installations. I completely understand and agree with the previous posters frustration with rbls. I have had the same trouble myself. I have had our company be on spamhaus and spamcop and different times in the last couple of years. It usually is a headache, but in general, they are more good than harm. At the real estate company, I have about 200 users that I can assure you would let me hear about it very quickly if they were not getting their messages. So far, I have not had any complaints using the rbls above.
Anyway, as I said before, you just have to find the proper balance for your situation. If you or your company cannot afford to lose even one email, it is probably best to put in very limited checks and use client-side filtering with Junk mailboxes. If speed of delivery is important, greylisting is not a good option. If you just want to stop the spam and it isn't the end of the world if you lose a possibly legitimate mail, then try out my settings above.
Hope this helps,
Preston
On 8/21/06, Grant <[EMAIL PROTECTED]> wrote:
I've followed the steps outlined here to eliminate spam up to the
section on "SPF and greylisting" on the second page:
http://www.freesoftwaremagazine.com/articles/focus_spam_postfix/
The author is really into greylisting:
"If you take nothing else from this article, let it be that
greylisting is a Good Thing and your customers will love you for using
it"
but the feedback I got on it from this list was not as positive. Of
the stuff I've implemented, these lines seem to have been the most
effective:
reject_rbl_client relays.ordb.org,
reject_rbl_client list.dsbl.org ,
reject_rbl_client sbl-xbl.spamhaus.org,
with the spamhaus.org line doing most of the work according to the logs.
Do you think the reject_rbl_client stuff is safer than greylisting?
- Grant
--
gentoo-user@gentoo.org mailing list
