On Wed, Jun 23, 2010 at 14:12, Noel Jones <[email protected]> wrote:

> It's about controlling when the check takes place.
> Some people like to reject unlisted recipients before other (maybe more
> expensive) checks.  Some people like to reject connections for RBL or
> blacklist before checking recipients to not "leak" information about valid
> recipients.
>
> It's about choice and local policy; either way is valid.

I suspected that.  But that is part of the question.  One is a list of
policies.  The other is one policy.  What is the relationship of the
single to the list?  If you have "smtpd_reject_unlisted_recipient =
yes" then does that happen before or after
"smtpd_recipient_restrictions = whatever"?  It seems that
smtpd_reject_unlisted_recipient is pointless since
"smtpd_recipient_restrictions" can do it AND be clear about what order
it is done.  Maybe smtpd_reject_unlisted_recipient is an older config
item?  But the documentation doesn't say it's no longer needed.


>> I had "smtpd_reject_unlisted_recipient = yes" but it doesn't seem to
>> work (it still accepts mail for unknown/non-existent recipients and
>> sends a bounce back).
>
> Then you broke recipient validation.  The most frequent cause of this is
> wildcard "@domain1 �...@domain2" entries in either virtual_alias_maps or
> *canonical_maps.

Obviously broken, but I don't have any entries like those.  So it's
something else.


> Bounces can also happen if your postfix rejects mail relayed from an
> upstream MTA, such as from your ISP or company gateway.  In this case the
> upstream MTA generates the bounce.

Only the one host is listed in MX.  This host is generating the bounce.


>> default_destination_concurrency_limit = 2
>
> Very low.  The default value usually sufficient.

I intended to eventually raise that.  I probably could now.  But I'm
focusing in the bounces of unknown users (e.g. the backscatter).  I
suspect the problem is related to doing the user verification through
Dovecot.  So I'm trying to set up another way to do it.


>> smtpd_recipient_restrictions =
>> permit_mynetworks       permit_sasl_authenticated
>> reject_unauth_destination       reject_unknown_recipient_domain
>> reject_unverified_recipient
>
> reject_unknown_recipient_domain after reject_unauth_destination can only
> reject your own domain. Think about it...  then remove it.

Someone suggested that in an example a while back and I never did
understand it.  Didn't break anything.  I didn't know how to make a
test case that would show whether it is there or not.  But maybe
that's the key ... maybe there can't be one.


>> soft_bounce = yes
>
> Only for testing!   Make sure to remove this once testing is completed.
>
>
>> unknown_local_recipient_reject_code = 450
>
> Only for testing!   Make sure to remove this once testing is completed.
>
>> unverified_recipient_reject_code = 450
>
> Usually only for testing.  Probably change this to 550 when testing is
> complete.

Even though it's in production, I had to roll it out before fine
tuning was done.  I'm trying to finish that up, now.  And for things
like tweaking what is rejected, I want to leave these in.

Reply via email to