[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

2024-04-24 Thread Viktor Dukhovni via Postfix-users
On Wed, Apr 24, 2024 at 07:23:00PM +0200, Kim Sindalsen via Postfix-users wrote: > > Regardless, as things stand, the default Fedora 39 nsswitch.conf > > makes Postfix restrictions much too fragile, and needs to be > > avoided. > > files dns is standard on my installation (Gentoo Linux/OpenRC) C

[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

2024-04-24 Thread Claus Assmann via Postfix-users
On Wed, Apr 24, 2024, Kim Sindalsen via Postfix-users wrote: > https://man.archlinux.org/man/nss-resolve.8.en seems to say that the order > should be: > mymachines resolve [!UNAVAIL=return] files myhostname Might be bad advice - we found this problem: If /etc/nsswitch.conf uses myhostname for th

[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

2024-04-24 Thread Kim Sindalsen via Postfix-users
> -Original Message- > From: Viktor Dukhovni via Postfix-users > Sent: 24. april 2024 09:19 > To: postfix-users@postfix.org > Subject: [pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux > nsswitch.conf files > > On Wed, Apr 24, 2024 at 07:43:35AM +0200, Reto via Postfix-user

[pfx] Re: Fun with line endings, was Re: Mail text wrapping

2024-04-24 Thread John Levine via Postfix-users
It appears that Viktor Dukhovni via Postfix-users said: >On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users wrote: > >> >I must be interpreting this wrong because it appears postfix is not >> >accepting that. Here is the complete process. A message arrives at >> >my MTA add

[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

2024-04-24 Thread Viktor Dukhovni via Postfix-users
On Wed, Apr 24, 2024 at 07:43:35AM +0200, Reto via Postfix-users wrote: > On Mon, Apr 22, 2024 at 03:50:34PM GMT, Viktor Dukhovni via Postfix-users > wrote: > > and this (specifically, !UNAVAIL=return) turns soft DNS failures into > > hard errors. > > > > The solution, on any production mail serv