From: URCentral Gmail ()
Date: Thu Oct 01 2009 - 12:21:53 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, Oct 1, 2009 at 6:46 PM, URCentral Gmail <urcentralgmail.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 'postmasterconfigcast.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
'postmasterconfigcast.com' in the first, but I guess that assumption
is incorrect?

Cya,
Jona

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]