Josh Cason a écrit : > I'm confused about the following in the main.cf > > smtpd_receipient_restrictions > smtpd_sender_restrictions > smtpd_client_restrictions > smtpd_data_restrictions ---- this I pretty much get > smtpd_helo_restrictions ---- this I pretty much get > > Now with postfix all of these are blank except > smtpd_receipient_restrictions. The default is something simple. Based on > mynetworks to let your network through and then reject unauthorized > destination to block anything else. Now it has turned into a real > nightmare. I treid to apply some ip numbers to the access list and it > did not work. I used my test server to backtrack the problem under > smtpd_client_restrictions with reject unknown client. So below is all my > restrictions. If you can clean them up or recommend anything to add. It > should help me have less problems. For example some people have reject > at the end of most everything while other have permit or leave blank. > > Thanks, > > Josh > > (I use pop-before-smtp) I get confused because the quick guide to pop to > smtp says to put reject_non_fqdn_recipeint. So then I ask why there and > not below. Seems like everybody has there own way of doing something and > as I found out today. It can cause problems. > > [snip]
an your problem is? stop copying things without unerstanding them. start with something fresh and only add checks that you _know_ are good for you. here are some notes about what you have now: - pop before smtp is weak. get rid of that. - cbl is included in sbl-xbl. - uribl don't want you to call thme the way you do. - rabl.nuclearelephant.com has never made it, and will never get anywhere. some people think they are good enough to stop spam, by their skills and superiority over others. thus the noise after "the plan for spam", "ending spam". that's only noise. they said Bayes. they said spf. they said dkim.did they say God? they said so many things. it is a fact that spam is a hard problem...
