RE: Need clarification of lookup table result values
> What is a valid result depends on what the result is used for: an > access table expects results as described in the access(5) manpage, > a virtual aliases table expects the results as described in the > virtual(5) manpage, a transport table expects results as described > in the transport(5) manpage, a the local aliases table expects > results as described in the aliases(5) manpage. You get the idea. Generally speaking, yes. But it's not so clear (to me) when applying to a specific case, like postscreen_access. > > > 2) Is there a difference between "OK" and "permit"? If so, what? > > 3) When can/should text follow the "reject" > > Those things are described in the access(5) manpage. Hmmm ... I don't see it. The access(5) manpage lists many valid result formats, including OK. Regarding OK and permit, it says: OK Accept the address etc. that matches the pattern. ... and then the only mention of permit is: restriction... Applythe named UCE restriction(s) (permit, reject, reject_unauth_destination, and so on). So I don't see the answer. In fact, OK doesn't seem to make sense for postscreen_access. After all, OK what? OK blacklist the address? OK whitelist the address? I realize the difficulty of documenting something that's so infinitely flexible. But without saying more explicitly what's allowed and what's not, there's just too much indirection (for me) to follow. So, back to my original question ... for postscreen_access.cidr: -- what would be the difference in behavior between using "OK" vs. "permit"? -- when can/should text follow the reject? Also, I can't find anywhere that says if the case matters. Is "PERMIT" equivalent to "permit"? Thanks, Michael
Re: relay_recipient_maps
On 5/28/2016 10:54 AM, Chris wrote: > Noel Jones wrote: > > Thank you for your reply. > >> No need to remove it. >> Most valid recipients will be cached in the verify table, and will >> be accepted. Uncached recipients will be temp-failed and should >> retry later when the main server is up. > > Ok, so I can just leave it as-is. It's for scheduled maintenance, so I > thought I setup a relay_recipients list to accept mails to all existing > recipients. But when Postfix uses the verify table anyway this isn't > necessary... > > - Chris > Yes, for a short outage, reject_unverified_recipient does the right thing.
Re: Need clarification of lookup table result values
Michael Fox: > 1) How can I tell which result values can be used in any given lookup > table? What is a valid result depends on what the result is used for: an access table expects results as described in the access(5) manpage, a virtual aliases table expects the results as described in the virtual(5) manpage, a transport table expects results as described in the transport(5) manpage, a the local aliases table expects results as described in the aliases(5) manpage. You get the idea. > 2) Is there a difference between "OK" and "permit"? If so, what? > 3) When can/should text follow the "reject" Those things are described in the access(5) manpage. > 4) Does "dunno" work the same as described in > http://www.postfix.org/access.5.html Yes, when used in an access table. As documented, "dunno" has no special meaning in virtual(5) or transport(5) or aliases(5). > 5) More generally, for any given table, how would I determine which > result values are allowed and what they will do? What is a valid result depends on what it is used for: an access table expects results as described in the access(5) manpage, and so on, as enumerated under my reply toi 1). Wietse
Re: whitelisting mime_header_checks whith extra smtpd and cleanup in master.cf
On 2016-05-27 22:00, Noel Jones wrote: The separate cleanup+header_checks must listen on a different IP:port. *urks* You'll need to arrange with the sender to use the alternate IP:port rather than your normal MX:25, or use firewall tricks to redirect the sender to the alternate IP:port. Both these are inconvenient and prone to breakage because they're different from normal mail flow. So... whitelisting (mime_)header_checks is not possible without fragile infrastructure changes that don't scale well. And it's not really whitelisting, it's exempting specified clients from any header_checks. Thanks for your comprehensive answer. I am convinced now, to go the amavisd-new way. It is the preffered tool to do what we need. Kind Regards, Konstantin
Re: whitelisting mime_header_checks whith extra smtpd and cleanup in master.cf
On 2016-05-27 12:21, wie...@porcupine.org wrote: For fine-grained content management, use amavisd-new, perhaps as a Okay, I am convinced, actually I am investigating how to integrate this tool. Yes, it is possible to use different header/body_checks on different IP addresses. Unfortunately, I do not have time to debug configurations based on fragments. But I realize a setup like this would be much more complicated than go the amavisd-new way. Thanks for your answer! Regards, Konsti
Need clarification of lookup table result values
I need some help understanding the valid "result" values that can be used in Postfix lookup tables and what the result values do. The examples I see in various places in the docs seem to contradict each other. As just one example, I'd like to configure postscreen_access.cidr. But I also need a broader understanding. http://www.postfix.org/DATABASE_README.html says nothing about result values http://www.postfix.org/POSTSCREEN_README.html shows an example that uses "permit" and reject" for a CIDR table. But http://www.postfix.org/cidr_table.5.html shows only an example that uses "OK" and "REJECT" without explaining their meaning/effect. http://www.postfix.org/access.5.html describes the effect of a variety of results for access-type tables. It says it works for DB, REGEXP and PCRE tables and smtpd, but it doesn't say that it works for CIDR tables nor for postscreen. So this leaves me with the following questions: 1) How can I tell which result values can be used in any given lookup table? 2) Is there a difference between "OK" and "permit"? If so, what? 3) When can/should text follow the "reject" 4) Does "dunno" work the same as described in http://www.postfix.org/access.5.html 5) More generally, for any given table, how would I determine which result values are allowed and what they will do? Thanks in advance, Michael
Re: relay_recipient_maps
On 5/28/2016 12:06 AM, Chris wrote: > Hi, > > is relay_recipient_maps parameter used if I add it to main.cf or are > special recipient or relay restrictions required? It's automatically used for any domain listed in relay_domains. > > Is there anything else to consider when my main server is down? Just want > to avoid backscatter from my relay. I guess I have to remove the > reject_unverified_recipient restriction then. No need to remove it. Most valid recipients will be cached in the verify table, and will be accepted. Uncached recipients will be temp-failed and should retry later when the main server is up. -- Noel Jones
