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