On Thu, Apr 07, 2011 at 12:20:51PM -0400, Victor Duchovni wrote:
> On Thu, Apr 07, 2011 at 05:57:24PM +0200, G?bor L?n?rt wrote:
> 
> > > Instead, Postfix requires that you have one or more of (reject,
> > > reject_unauth_destination, etc.) SOMEWHERE in
> > > sender_recipient_restrictions.
> > 
> > I have the needed rejects at the sender, but not at the recipient, because I
> > have the idea that if I reject "unwanted" things at the sender, I am safe
> > not to do the same restrictions at the recipient restrictions.
> 
> You are confused. The above is simply wrong. Either the timing is
> identical for both checks, and you gain nothing, or critical data (the
> recipient domain) is missing at sender stage (if smtpd_delay_reject=no,
> which is not recommended).

I meant that I rejected everything at the sender restrictions which are
based on information available at sender or maybe even earlier. Of course,
information like recipient based things can't be rejected at the sender,
it's done at the recipient. 

Ok, I've tried to do what I want (it seems to work ... but hmmm), the
important part:

smtpd_sender_restrictions =
        reject_unauth_pipelining,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        check_sender_access pcre:/etc/postfix/check_address_syntax.pcre,
        check_sender_access mysql:/etc/postfix/banned_senders.sql,
        check_sender_mx_access cidr:/etc/postfix/mx_access.cidr,
        permit_sasl_authenticated,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_client_access cidr:/etc/postfix/ip_based_relay.cidr,
        check_client_access ldap:/etc/postfix/ip_based_relay.ldap,
        reject
smtpd_recipient_restrictions =
        reject_unauth_pipelining,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        check_recipient_access pcre:/etc/postfix/check_address_syntax.pcre,
        check_recipient_access mysql:/etc/postfix/banned_rcpts.sql,
        check_recipient_mx_access cidr:/etc/postfix/mx_access.cidr,
        check_recipient_access static:OK,
        reject

Here, I want a setup which rejects things as soon as possible (of course
recipient based things can't be rejected as the sender), I would have sasl
authenticated users and also some others who can go given by their IPs: for
those, stricted helo checks are needed too.

What I meant, that if I want to be "not so ugly, I should have these
instead of that ugly static:OK and reject, at the end of
smtpd_recipient_restrictions too:

        permit_sasl_authenticated,
        check_client_access cidr:/etc/postfix/ip_based_relay.cidr,
        check_client_access ldap:/etc/postfix/ip_based_relay.ldap,
        reject

So I basically duplicate these steps then which is already done in
smtpd_sender_restrictions too.

Or maybe, I should not be so nervous (as I've mentioned) and do those checks
_only_ at smtpd_recipient_restrictions so I don't need to worry about this
issue, however then my goal (which can be odd, anyway) fails that I want to
reject things as soon as possible (to be honest, the previous system acts
this way, and to minimalize noticable changes I wanted to do a postfix based
solution which acts as close as possible to the old solution, so users won't
notice too much changes).

And I am also wondering why there is "smtpd_sender_restrictions" exits in
postfix when very checks could be done later too because sender etc based
checks are possible at smtpd_recipient_restrictions too, and also
smtpd_delay_reject=no is not recommended, as you told

But I believe all of you, maybe I should not complicate things which can
cause problems for other admins later, or maybe newer postfix releases in
the future etc etc etc.

Thanks to all for the opinions about the issue!

> > The whole
> > issue is because I want to reject things as soon as possible (heavy
> > traffic),
> 
> Premature optimization is the root of all evil.

that seems to be true :)

Reply via email to