smtpd_recipient_restrictions = reject_unlisted_recipient vs. smtpd_reject_unlisted_recipient = yes
in [Postfix]
|
Prev: smtpd_recipient_restrictions = reject_unlisted_recipient vs.smtpd_reject_unlisted_recipient = yes
Next: virtual_mailbox_maps - just for virtual(8) ?
From: Noel Jones on 23 Jun 2010 14:12 On 6/23/2010 12:15 PM, Phil Howard wrote: > The default for smtpd_reject_unlisted_recipient is yes. How does that > affect using reject_unlisted_recipient in > smtpd_recipient_restrictions? It allows you to control *when* the check is performed. > Does it mean it is effectively included > whether you include it or not? It means the default is to check for unlisted recipients after smtpd_recipient_restrictions are evaluated. > 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. 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 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. 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. > > This is not the only variation I have tried, but here is where I am at > the moment: > .... > default_destination_concurrency_limit = 2 Very low. The default value usually sufficient. > 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. > 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. > virtual_alias_maps = cdb:/etc/postfix/virtual > virtual_mailbox_domains = /etc/postfix/domains > virtual_transport = dovecot -- Noel Jones
From: Noel Jones on 23 Jun 2010 14:25 On 6/23/2010 1:12 PM, Phil Howard wrote: > 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 >> > > Does "postconf -n | grep dovecot" show it for you? Does not for me. It's not expected to show. mumble_destination_recipient_limit and other user-defined parameters do not appear in postconf output. See the postconf man page for details. -- Noel Jones
From: Noel Jones on 23 Jun 2010 16:02
On 6/23/2010 2:12 PM, Phil Howard wrote: > 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? They do the same thing. You can choose to let the default setting take care of it, or you can control it yourself. > If you have "smtpd_reject_unlisted_recipient = > yes" then does that happen before or after > "smtpd_recipient_restrictions = whatever"? After. This is not specifically documented, so is subject to change. > 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. It's harmless to leave it set -- postfix doesn't repeat the check -- so the docs doesn't address it. It's not practical for the documentation to list everything you should *not* do, or everything you can do that's pointless. Read the HISTORY file included with postfix and list archives for details about where something came from. > > >>> 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. Open a new thread for that problem. Include evidence such as "postconf -n", and postfix log entries of unwanted behavior. -- Noel Jones |