From: Phil Howard on
The default for smtpd_reject_unlisted_recipient is yes. How does that
affect using reject_unlisted_recipient in
smtpd_recipient_restrictions? Does it mean it is effectively included
whether you include it or not? I presume I still need to list other
things like "smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated" so I don't see the point in having a
separate smtpd_reject_unlisted_recipient.

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).

This is not the only variation I have tried, but here is where I am at
the moment:

alias_database = cdb:/etc/postfix/aliases
alias_maps = cdb:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
default_destination_concurrency_limit = 2
default_privs = nobody
in_flow_delay = 1s
inet_protocols = ipv4, ipv6
local_destination_concurrency_limit = 2
mail_owner = postfix
mydomain = DOMAIN.NAME
myhostname = mx.DOMAIN.NAME
mynetworks = 127.0.0.0/8, 172.16.0.0/12, [::1]/128, [fcca::]/7, [fe80::]/48
myorigin = $mydomain
proxy_interfaces = FIRE.WALL.IP.ADDR
queue_directory = /var/spool/postfix
recipient_delimiter = +
smtp_bind_address = 172.30.0.25
smtp_bind_address6 = fcca::25
smtpd_banner = $myhostname ESMTP - UNSOLICITED BULK OR ILLEGAL EMAIL
IS STRICTLY PROHIBITED
smtpd_recipient_restrictions =
permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_recipient_domain reject_unverified_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/smtp.DOMAIN.NAME.crt
smtpd_tls_key_file = /etc/ssl/private/smtp.DOMAIN.NAME.key
smtpd_tls_security_level = may
soft_bounce = yes
unknown_local_recipient_reject_code = 450
unverified_recipient_reject_code = 450
virtual_alias_maps = cdb:/etc/postfix/virtual
virtual_mailbox_domains = /etc/postfix/domains
virtual_transport = dovecot

From: Phil Howard on
On Wed, Jun 23, 2010 at 13:55, Jerry <postfix-user(a)seibercom.net> wrote:

> I use Dovecot for virtual transport also. I don't remember exactly why;
> however, I had to place this in the main.cf file:
>
>        dovecot_destination_recipient_limit = 1
>
> By the way, your "smtpd_banner" may make you feel good, but like most
> disclaimers and oral contracts, it isn't worth the paper it is printed
> on. In fact, it almost sounds like a challenge.

Does "postconf -n | grep dovecot" show it for you? Does not for me.
I don't know why that is, but I suspect it is due to the fact that
this is a dynamically named transport variable. Maybe what postconf
is doing is iterating through its known list of variables and
displaying them in that order, and
${whateveryourtransportis}_destination_recipient_limit (and a few
others) are not really "known" in that context. I remember that
confused me in the past because I was literally looking for
"dovecot_*" stuff in the documentation and not finding it. Now I know
to literally use "transport" for the transport name to find
documentation.

================================================================
marconi/root/x0 /etc/postfix 132# postconf -n | grep dovecot
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_type = dovecot
virtual_transport = dovecot
marconi/root/x0 /etc/postfix 133# grep dovecot < main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
marconi/root/x0 /etc/postfix 134#
================================================================

From: Phil Howard on
On Wed, Jun 23, 2010 at 14:12, Noel Jones <njones(a)megan.vbhcs.org> 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.