smtpd_recipient_restrictions = reject_unlisted_recipient vs. smtpd_reject_unlisted_recipient = yes
in [Postfix]
|
Prev: A list in a file
Next: smtpd_recipient_restrictions = reject_unlisted_recipient vs.smtpd_reject_unlisted_recipient = yes
From: Phil Howard on 23 Jun 2010 13:15 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 23 Jun 2010 14:12 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 23 Jun 2010 15:12
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. |