On Sun, May 29, 2022 at 12:12:29PM +1000, raf wrote:
> On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote:
>
> > For completeness here's everything I can think of that could be
> > related:
> >
> > $ ls -ld /etc/sasl2
> > drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2
> >
> > $ l
On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote:
> For completeness here's everything I can think of that could be
> related:
>
> $ ls -ld /etc/sasl2
> drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2
>
> $ ls -l /etc/sasl2/
> -rw-r--r-- 1 root root 62 May 28 18:18 smtpd.conf
>
On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote:
> Foreground saslauthd command, including debug output from
> successful testsaslauthd but no log entries corresponding to the
> immediately above extract from the Postfix log:
>
> $ sudo saslauthd -a pam -d -c -m /var/spool/postfix/va
On 29/05/22 12:11 pm, Jim Garrison wrote:
1) The command I got from an internet post to generate the base64
encoded user/password was incorrect, or intended for a different
version of the echo command. In
$ echo -ne '\000myu...@mydomain.com\000[password]' | base64
bash echo expe
On 5/28/2022 2:21 PM, Viktor Dukhovni wrote:
[ Please respect the "Reply-To" header]
Oops, sorry, will do.
I'm making some progress. I turned on debug tracing in postfix and
saslauthd and made some interesting discoveries:
1) The command I got from an internet post to generate the base64
e
On Fri, May 27, 2022 at 06:22:01PM -0700, Jim Garrison wrote:
> I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos
> 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working
> EXCEPT SASL authentication, and the amount of conflicting information
> on Postfix+SASL
[ Please respect the "Reply-To" header]
On Sat, May 28, 2022 at 12:47:24PM -0700, Jim Garrison wrote:
> On 5/27/2022 8:31 PM, Viktor Dukhovni wrote:
> > Why not just read the SASL_README that comes with Postfix, e.g. at:
> >
> > https://www.postfix.org/SASL_README.html
>
> OK, I did just
On Sat, May 28, 2022 at 03:09:40PM +0200, Joachim Lindenberg wrote:
> I don´t get why defining a different transport per domain should be
> easier than defining a tls policy per domain, and my configuration is
> mostly automated anyway.
Not *per-domain*, per TLS security level. All domains that
Hello Victor,
I don´t get why defining a different transport per domain should be easier than
defining a tls policy per domain, and my configuration is mostly automated
anyway. The automated part becomes a challenge right now with a combination of
dead mx plus insecure mx only - and the issue is
