postscreen will not invoke tests for every connection, nor will it
store configuration overrides in its cache. You can build your own
MTA front-end, or convince some other project to build DNSBL lookups
into their loadbalancer or proxy.
Wietse
On Mon, Sep 19, 2016 at 7:19 PM, Wietse Venema wrote:
> What you are asking for requires either that a test happens for
> every connection, or the ability to store configuration overrides
> in the postscreen cache. The first is not a good idea, and the
> latter just adds complexity.
>
> The first
Jose Borges Ferreira:
> That is great!
>
> Can you consider override smtpd_service_name based on the reply ?
> This would allow to have different smtpd profiles depending on some
> criteria defined in the policy daemon .
The result of a postscreen test is either 'pass' which is cached,
or some fl
> On Sep 19, 2016, at 12:05 PM, Viktor Dukhovni
> wrote:
>
> Outbound TLS policy by sender is not directly supported, but
> if you're willing to configure separate transports for sufficiently
> large groups of users that desire the same outbound TLS policy, you
> can employ:
>
>
> http://w
> On Sep 19, 2016, at 11:35 AM, Tom Johnson wrote:
>
>
> At first I was thinking "Great, this could help us allow users to have
> enforced TLS for certain senders/recipients", but then I realized that this
> policy is probably be happening after the STARTTLS command, right?
No postscreen(8)
> On Sep 19, 2016, at 7:50 AM, Jose Borges Ferreira
> wrote:
>
> That is great!
>
> Can you consider override smtpd_service_name based on the reply ?
> This would allow to have different smtpd profiles depending on some criteria
> defined in the policy daemon .
>
At first I was thinking "Gr
That is great!
Can you consider override smtpd_service_name based on the reply ?
This would allow to have different smtpd profiles depending on some
criteria defined in the policy daemon .
Thanks,
José Borges Ferreira
On Sun, Sep 18, 2016 at 2:40 AM, Wietse Venema wrote:
> This is a rough des
