| 1 |
I think the thing you have to keep in mind is how strict you want to be. I |
| 2 |
am in control of mail servers for three different "organizations", my |
| 3 |
personal email, my consulting side business, and the real estate company I |
| 4 |
work full time for. Each one has a varying degree of how acceptable false |
| 5 |
positives are. For my personal email, I use the following settings: |
| 6 |
|
| 7 |
smtpd_delay_reject = yes |
| 8 |
smtpd_helo_required = yes |
| 9 |
smtpd_helo_restrictions = |
| 10 |
permit_mynetworks, |
| 11 |
check_helo_access |
| 12 |
hash:/etc/postfix/helo_access, |
| 13 |
reject_non_fqdn_hostname, |
| 14 |
reject_invalid_hostname, |
| 15 |
permit |
| 16 |
|
| 17 |
smtpd_sender_restrictions = |
| 18 |
permit_sasl_authenticated, |
| 19 |
permit_mynetworks, |
| 20 |
reject_non_fqdn_sender, |
| 21 |
reject_unknown_sender_domain, |
| 22 |
permit |
| 23 |
|
| 24 |
smtpd_recipient_restrictions = |
| 25 |
reject_unauth_pipelining, |
| 26 |
reject_non_fqdn_recipient, |
| 27 |
reject_unknown_recipient_domain, |
| 28 |
permit_mynetworks, |
| 29 |
permit_sasl_authenticated, |
| 30 |
reject_unauth_destination, |
| 31 |
reject_rbl_client relays.ordb.org, |
| 32 |
reject_rbl_client list.dsbl.org, |
| 33 |
reject_rbl_client sbl-xbl.spamhaus.org, |
| 34 |
reject_rbl_client bl.spamcop.net, |
| 35 |
reject_rbl_client dnsbl.njabl.org, |
| 36 |
check_policy_service inet:127.0.0.1:60000 |
| 37 |
permit |
| 38 |
|
| 39 |
|
| 40 |
The check_policy_service inet:127.0.0.1:60000 is for postgrey, a greylisting |
| 41 |
service. Personally, I hate spam so much, I would rather block my own |
| 42 |
mother's emails than get spam. The checks above with postgrey have brought |
| 43 |
me from about 15-20 spam a day to 0 since I have had them in effect. On the |
| 44 |
otherhand, for the real estate company I work for, some of these options are |
| 45 |
not acceptable. Postgrey is not acceptable since many of our users expect |
| 46 |
email to be "instant" I know there is no technical guarantee of this, but |
| 47 |
they get upset no matter what if their emails take too long. Using postgrey |
| 48 |
on my own personal server, I make it delay for 5 minutes. Most mail servers |
| 49 |
will keep trying and I will get the message within 10-15 minutes max. I |
| 50 |
have had a few times, though, that the mail took 4 or 5 hours before it was |
| 51 |
tried again. A solution I use for this for my consulting business is to |
| 52 |
whitelist all of my clients domains. With the real estate company, however, |
| 53 |
there are too many different users working with too many different and new |
| 54 |
companies to try and whitelist them all. |
| 55 |
|
| 56 |
I actually do keep the rbls for all installations. I completely understand |
| 57 |
and agree with the previous posters frustration with rbls. I have had the |
| 58 |
same trouble myself. I have had our company be on spamhaus and spamcop and |
| 59 |
different times in the last couple of years. It usually is a headache, but |
| 60 |
in general, they are more good than harm. At the real estate company, I |
| 61 |
have about 200 users that I can assure you would let me hear about it very |
| 62 |
quickly if they were not getting their messages. So far, I have not had any |
| 63 |
complaints using the rbls above. |
| 64 |
|
| 65 |
Anyway, as I said before, you just have to find the proper balance for your |
| 66 |
situation. If you or your company cannot afford to lose even one email, it |
| 67 |
is probably best to put in very limited checks and use client-side filtering |
| 68 |
with Junk mailboxes. If speed of delivery is important, greylisting is not |
| 69 |
a good option. If you just want to stop the spam and it isn't the end of |
| 70 |
the world if you lose a possibly legitimate mail, then try out my settings |
| 71 |
above. |
| 72 |
|
| 73 |
Hope this helps, |
| 74 |
|
| 75 |
Preston |
| 76 |
|
| 77 |
On 8/21/06, Grant <emailgrant@×××××.com> wrote: |
| 78 |
> |
| 79 |
> I've followed the steps outlined here to eliminate spam up to the |
| 80 |
> section on "SPF and greylisting" on the second page: |
| 81 |
> |
| 82 |
> http://www.freesoftwaremagazine.com/articles/focus_spam_postfix/ |
| 83 |
> |
| 84 |
> The author is really into greylisting: |
| 85 |
> |
| 86 |
> "If you take nothing else from this article, let it be that |
| 87 |
> greylisting is a Good Thing and your customers will love you for using |
| 88 |
> it" |
| 89 |
> |
| 90 |
> but the feedback I got on it from this list was not as positive. Of |
| 91 |
> the stuff I've implemented, these lines seem to have been the most |
| 92 |
> effective: |
| 93 |
> |
| 94 |
> reject_rbl_client relays.ordb.org, |
| 95 |
> reject_rbl_client list.dsbl.org, |
| 96 |
> reject_rbl_client sbl-xbl.spamhaus.org, |
| 97 |
> |
| 98 |
> with the spamhaus.org line doing most of the work according to the logs. |
| 99 |
> |
| 100 |
> Do you think the reject_rbl_client stuff is safer than greylisting? |
| 101 |
> |
| 102 |
> - Grant |
| 103 |
> -- |
| 104 |
> gentoo-user@g.o mailing list |
| 105 |
> |
| 106 |
> |
Archives