On 5/18/2010 5:43 PM, Josh Cason wrote: > 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.
The difference is what is available to check and when they are evaluated (in order): client_restrictions: apply on connect after parsing client info helo_restrictions: apply on [HE]LO sender_restrictions: apply on "MAIL FROM" recipient_restrictions: apply on "RCPT TO" However, smtpd_delay_reject comes into play with all these restrictions. The default, yes, allows all restrictions to be evaluated at "RCPT TO" and all information available up to and including recipient. Changing this to no makes rejects come faster and restricts what is available to check as per postconf(5). Some clients may have problems if reject comes too early. > > 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. IMHO, pop-before-smtp is a slowly deprecating technology that is being supplanted by SASL authorization. > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_client_access hash:/etc/postfix/access, > check_client_access hash:/etc/postfix/pop-before-smtp, > reject_unauth_destination, > reject_non_fqdn_recipient, > reject_unlisted_recipient, > reject_unknown_sender_domain, > reject_unverified_sender, > reject_multi_recipient_bounce, > reject_invalid_hostname, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > check_helo_access regexp:/etc/postfix/helo.regexp, > reject_rbl_client multi.uribl.com, > reject_rbl_client dsn.rfc-ignorant.org, > reject_rbl_client dul.dnsbl.sorbs.net, > reject_rbl_client sbl-xbl.spamhaus.org, > reject_rbl_client bl.spamcop.net, > reject_rbl_client dnsbl.sorbs.net, > reject_rbl_client cbl.abuseat.org, > reject_rbl_client ix.dnsbl.manitu.net, > reject_rbl_client combined.rbl.msrbl.net, > reject_rbl_client rabl.nuclearelephant.com Consider using zen.spamhaus.org instead of sbl-xbl.spamhaus.org and cbl.abuseat.org simply for less checks and faster processing. multi.uribl.com may not be very useful here. According to their site, it's more useful in SpamAssassin or similar since it is a URI blacklist. It is good practice to reevaluate rbls periodically for accuracy and your policy. Some die or go stale after a while. > > > smtpd_data_restrictions = > reject_unauth_pipelining, > reject_multi_recipient_bounce, > permit > > # Requirements for the sender details > smtpd_sender_restrictions = > permit_mynetworks, > reject_non_fqdn_sender, > reject_unknown_sender_domain, > reject_unauth_pipelining, > check_sender_access hash:/etc/postfix/sender_access, > permit > > (do I really need pop-before-smtp there? Somebody else had it in a > example?) > > # Requirements for the connecting server > smtpd_client_restrictions = > permit_mynetworks, > check_client_access hash:/etc/postfix/access, > check_client_access hash:/etc/postfix/pop-before-smtp, > reject_unknown_client, > reject_rbl_client sbl.spamhaus.org, > reject_rbl_client dnsbl.njabl.org, > reject_unauth_destination This looks very repetitive of your smtpd_recipient_restrictions. You also query the same RBL twice using different hosts which will double your DNS questions with the same response. > > smtpd_helo_restrictions = > permit_mynetworks, > regexp:/etc/postfix/helo.regexp, > permit helo.regexp is checked twice and will give the same result each time. Here it implies check_helo_access.
