README.Debian says that sasl stuff goes in /etc/postfix/sasl.
If I put it there it doesn't work; I have to put it in /etc/postfix.

Dear Maintainer,

   * What led up to the situation?

After upgrading from bookworm to trixie postfix authentication started failing.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Upgrade postfix from bookworm to trixie

   * What was the outcome of this action?

sasl authentication with ldap backend was broken.

mail.log only showed connection was broken

2026-02-28T05:55:26.327940-08:00 comms-staging postfix/submission/smtpd[2086]:
connect from unknown[106.222.210.148]
2026-02-28T05:55:34.607009-08:00 comms-staging postfix/submission/smtpd[2086]:
NOQUEUE: lost connection after EHLO from unknown[106.222.210.148]
2026-02-28T05:55:34.607273-08:00 comms-staging postfix/submission/smtpd[2086]:
disconnect from unknown[106.222.210.148] ehlo=2 starttls=1 commands=3

and msmtp showed

$ msmtp -a praveen1@domain.tld  -t <smtp_test.txt
password for praveen at comms-staging.domain.tld:
msmtp: GNU SASL: Error authenticating user
msmtp: could not send mail (account praveen1@domain.tld from
/home/pravi/.msmtprc)

   * What outcome did you expect instead?

postfix should continue working with saslauthd.

Then I compared postconf output from a freshly installed postfix on another
system and found

It had cyrus_sasl_config_path = /etc/postfix/sasl

Adding this to main.cf fixed the issue. Since this breaks upgrades, this should
be documented in the NEWS file (until bookworm this was not required).

Control: tag -1 + moreinfo unreproducible
Control: severity -1 normal

When upgrading from bookworm version to trixie version, the package
checks if cyrus_sasl_config_path is specified in the old config,
and if not, sets it to /etc/postfix/sasl.  This is the fragment from
the postinst script which does this:

if dpkg --compare-versions "$OLDVERSION" lt-nl 3.9.0-3~
then
     # cyrus_sasl_config used to be hard-coded in debian to
/etc/postfix/sasl.
     # Since 3.9.0-3 we switched to upstream default which is empty,
     # which means to use built-in Cyrus SASL library defaults.
     # Debian policy says it should be /etc/postfix/sasl
     if [ ! "$(postconf -hx cyrus_sasl_config_path)" ]; then
         postconf -e cyrus_sasl_config_path=/etc/postfix/sasl
     fi
fi


I verified upgrades from various different versions of postfix package,
and the upgrade definitely adds this configuration item.  A lot of users
with cyrus sasl upgraded their systems flawlessly.  Just yesterday I
upgraded another bookworm system to trixie, including postfix, and the
procedure added

  cyrus_sasl_config_path = /etc/postfix/sasl

to main.cf, even if I don't use cyrus or sasl in general.

So this should be something on your system which breaks this workaround.

Please find out what's different on your system.
Which was the version of postfix you're upgrading from?

There's definitely no reason to add news entries saying upgrade will
break your system if it doesn't happen for everyone else.

Also, it's a bad habit to hijack an old bug report which talks about
a version which were many debian releases ago - it's unlikely to be
the same issue.

Thanks,

/mjt

I maintain main.cf as a template in ansible. So I need to make this
change manually to the configuration file. This would be the case for
people using configuration management tools like ansible.

After postfix was updated, I have applied the main.cf in my ansible
templates which removed this entry. I later found it out by comparing
the postconf output on a freshly installed system.

As I said, it will break anyone using a configuration management system
like ansible as they need to make this change in their template
configuration as well. So I think it deserves a mention in the NEWS file.

I have seen people recommending to check existing issues and comment on
them rather than opening new issues.

On 03.03.2026 21:56, Pirate Praveen wrote:
...

Aha, this makes sense indeed - when you remove carefully added
configuration changes aimed to keep your system running, things
will break, unless you take care of them somehow.  Maybe paying
attention to `ansible-playbook -CD` output after upgrade is a
good idea too.

It's always a trade-off, - as I said, you're the only one who faced this
issue so far (it's been quite a number of upgrades since trixie is out).
For the rest of users, such NEWS entry would be a useless noise.
There's already quite some differences in postfix packaging in trixie
(removal of the postfix@- unit etc).  I wanted to keep it as compact as
possible.  Adding this change to NEWS didn't occur to me at all, though,
because it seemed like something which I solved by editing config.

Yeah. When it's the same issue.

But doesn't matter anymore.  That bug was not useful anyway, 17 years
after its been filed.

/mjt

Usual practice with apt/dpkg is giving a manual prompt if maintainer
supplied config conflicts with user modified changes, letting the user
inspect changes manually. I'm not sure if other packages edit config
files through a postinst script.

I think editing config files in postinst is not a standard way users
expect to know about a config change, so I still think this would be
useful. But I'll let you make the call as the maintainer.

I'm not sure if any other change has an high impact like this.
I thought this was pretty close as it was talking about the sasl path
needing manual action, though why this was needed indeed changed.