On Thu, Oct 1, 2009 at 6:46 PM, URCentral @ Gmail <urcent...@gmail.com> wrote:
>>> Is this by design, working as intended? Or am I missing something somewhere?
>>
>> Where's the main.cf snippet?
>
> Guess I did miss something somewhere. This is how it looks like now;
>
> 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
> reject_non_fqdn_recipient
> reject_unknown_recipient_domain
> check_recipient_access
> hash:/etc/postfix/chk_recipient_access
> reject_unverified_recipient
>
>
> 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
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
