URCentral @ Gmail wrote: > On Thu, Oct 1, 2009 at 6:46 PM, URCentral @ Gmail <urcent...@gmail.com> wrote: > >> Which works; if 'postmas...@configcast.com' is used as a sender, it >> rejects the rest of the SMTP session, but if used as a recipient, it's >> fine, as expected. If I move 'check_sender_access' to the next stage >> however, like this; >> >> smtpd_sender_restrictions = >> permit_mynetworks >> reject_unknown_sender_domain >> reject_non_fqdn_sender >> check_sender_access >> hash:/etc/postfix/chk_sender_access >> >> smtpd_recipient_restrictions = >> permit_mynetworks >> reject_unknown_reverse_client_hostname >> reject_non_fqdn_helo_hostname >> reject_unknown_helo_hostname >> reject_unauth_destination >> check_sender_access >> hash:/etc/postfix/chk_sender_access >> reject_non_fqdn_recipient >> reject_unknown_recipient_domain >> check_recipient_access >> hash:/etc/postfix/chk_recipient_access >> reject_unverified_recipient >> >> then it will reject the recipient with the action specified in the >> 'check_sender_access' hash database; >> >> configcast.com REJECT You are not a known MX for >> 'configcast.com'. >> > > Correcting myself; there are two hash databases specified on the live > server, like this; > > check_sender_access > hash:/etc/postfix/chk_sender_local > hash:/etc/postfix/chk_sender_access > >
If this was specified in recipient restrictions, it is equivalent to: check_sender_access hash:/etc/postfix/chk_sender_local check_recipient_access hash:/etc/postfix/chk_sender_access This refers to the depreciated syntax of bare map in a restriction class. Postfix does not allow check_(*)_access to list multiple tables. The restriction *must* be repeated each time or an assumption takes place based on the past. > The 'chk_sender_local' is currently empty. If I remove the first one > so it actually matches the example given above, with just one hash > database, the problem disappears and it works as expected. > > From the various examples I've seen I assumed that several type:table > pairs per restriction are possible, and I can override the > restrictions set in the second database by giving an 'OK' for > 'postmas...@configcast.com' in the first, but I guess that assumption > is incorrect? > > Cya, > Jona >
