On Wed, Oct 27, 2021 at 06:36:14AM -0400, Wietse Venema
wrote:
> Dan Mahoney:
> > I've wondered this for a while, and have even suggested the day
> > job implement this in our own software.
> >
> > This feels like a reasonable place to ask. Is there a way, given
> > a new warning about
Dan Mahoney:
> I've wondered this for a while, and have even suggested the day
> job implement this in our own software.
>
> This feels like a reasonable place to ask. Is there a way, given
> a new warning about compatibility_level (say you've been running
> with 3_5, and you're now running 3_6),
On Tue, Oct 26, 2021 at 08:50:38PM -0400, Viktor Dukhovni
wrote:
> On Tue, Oct 26, 2021 at 08:41:20PM -0400, Viktor Dukhovni wrote:
>
> > With `bash` inline /dev/fd/ files:
> >
> > $ diff -U0 <(postconf -x -o compatibility_level=2) <(postconf -x -o
> > compatibility_level=3.6)
>
> A
On Tue, Oct 26, 2021 at 08:41:20PM -0400, Viktor Dukhovni wrote:
> With `bash` inline /dev/fd/ files:
>
> $ diff -U0 <(postconf -x -o compatibility_level=2) <(postconf -x -o
> compatibility_level=3.6)
A handly abstraction to a couple function definitions would be:
compatconf() {
On Wed, Oct 27, 2021 at 11:34:57AM +1100, raf wrote:
> > Is there a way, given a new warning about compatibility_level (say
> > you've been running with 3_5, and you're now running 3_6), to see
> > what changes to your config are effectively made by enabling that
> > level? (effectively, to show
On Tue, Oct 26, 2021 at 05:08:00PM -0700, Dan Mahoney
wrote:
>
>
> > On Oct 26, 2021, at 4:54 PM, raf wrote:
> >
> > On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
> > wrote:
> >
> >> Vincent Pelletier:
> >>> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
> >>> Wietse Venema wrote :
> On Oct 26, 2021, at 4:54 PM, raf wrote:
>
> On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
> wrote:
>
>> Vincent Pelletier:
>>> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
>>> Wietse Venema wrote :
This would require a new setting, for example to make smtp_bind_address
On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
wrote:
> Vincent Pelletier:
> > On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
> > Wietse Venema wrote :
> > > This would require a new setting, for example to make smtp_bind_address
> > > failures a retryable error.
> > >
> > >
post...@ptld.com:
> >> It does not complicate the code. I am more concerned about
> >> discoverability (how would a user even find out that the behavior
> >> has become configurable).
> >
> > The best we can do is cross-reference the new parameter under
> > smtp_bind_address (and IPv6
It does not complicate the code. I am more concerned about
discoverability (how would a user even find out that the behavior
has become configurable).
The best we can do is cross-reference the new parameter under
smtp_bind_address (and IPv6 equivalent), and then sufficiently
motivated
users
On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema wrote:
> It does not complicate the code. I am more concerned about
> discoverability (how would a user even find out that the behavior
> has become configurable).
The best we can do is cross-reference the new parameter under
Vincent Pelletier:
> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
> Wietse Venema wrote :
> > This would require a new setting, for example to make smtp_bind_address
> > failures a retryable error.
> >
> > smtp_bind_address_failure_action = warn (or defer)
> >
> > warn: current behavior
> > defer:
On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
Wietse Venema wrote :
> This would require a new setting, for example to make smtp_bind_address
> failures a retryable error.
>
> smtp_bind_address_failure_action = warn (or defer)
>
> warn: current behavior
> defer: treat as a faiilure to connect
This
Vincent Pelletier:
> I would rather postfix just stop sending emails altogether in such case,
> than send them from an unexpected ip: a delay is preferable to me to
> uncertainty as to how the emails were processed by recipient SMTPs.
>
> Is there something else I should set so postfix stops
On Mon, Oct 25, 2021 at 09:35:35AM +, Vincent Pelletier wrote:
> I would rather postfix just stop sending emails altogether in such
> case, than send them from an unexpected ip: a delay is preferable to
> me to uncertainty as to how the emails were processed by recipient
> SMTPs.
>
> Is
On 25/10/2021 11:35, Vincent Pelletier wrote:
I would rather postfix just stop sending emails altogether in such case,
than send them from an unexpected ip: a delay is preferable to me to
uncertainty as to how the emails were processed by recipient SMTPs.
As a categorical prevention of postfix
Hello,
I have a server with multiple IPv4 routes to the internet (multipath
over tunnels, plus the default route). The multipath route is picked for
outgoing connections based on the IP the client socket is bound to:
ip rule from lookup
ip route add table default nexthop via ... [nexthop
17 matches
Mail list logo
