I'll start by stating clearly that I haven't used SASLDB in ages, and don't use auxprop, but what jumps out at me from the git log is this line:

 * de822fc Enable sasldb authentication mechanism

Since OP has been using auxprop, perhaps the proper fix will be to figure out just what's meant by that commit message, and reverse it (or fix it).
    -nic

On 6/8/23 12:48, Simo Sorce wrote:
This is the diff between F37 and F36, maybe you'll find some clue
there:

$ git log --oneline origin/f36..origin/f37
e0d1e57 (origin/f37) Avoid requires on systemd as well as per updated
guidelines
db25e25 Avoid systemd_requires as per updated packaging guidelines
a64513d (HEAD -> rawhide) Fix memory leak in digestmd5 patches
b96caf4 Rebuilt for
https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
7f6beb6 (pag/sysusers, sysusers) Use systemd sysusers to create
saslauth user
de822fc Enable sasldb authentication mechanism
a1359a4 (pag/rawhide, pag/main) Fix changelog section with correct
syntax
eba3ea5 Update to 2.1.28
b229146 Move to use autorelease macro
d09a799 Move to use the autochangelog macro

HTH,
Simo.


On Thu, 2023-06-08 at 10:39 -0600, Philip Prindeville wrote:
Hi,

I had been running F36 and updated to F37.  After rebooting, authentication 
started failing (seemingly sporadically).

I'm seeing:

Jun  8 10:32:10 mail cyrus/imaps[16976]: starttls: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits new) no authentication
Jun  8 10:32:10 mail cyrus/imaps[16976]: client id sessionid=<cyrus-1686241930-16976-1-13642841045060016715>: "name" "Mac OS X Mail" "version" 
"16.0 (3731.600.7)" "os" "Mac OS X" "os-version" "13.4 (22F66)" "vendor" "Apple Inc."
Jun  8 10:32:10 mail cyrus/imaps[16976]: badlogin: 
macbook3-3.redfish-solutions.com [192.168.8.12] CRAM-MD5 (-notset-) [SASL(-13): 
user not found: user:joeb...@mail.redfish-solutions.com  property: 
cmusaslsecretCRAM-MD5 not found in /etc/sasl2/sasldb2]

But I shouldn't be seeing any domain at all (or realm, whichever) when the SASL 
lookups are done.

This has worked in my configuration for years.  Not sure why it's suddenly 
failing with the update.

The relevant part of my /etc/imapd.conf is:

sasl_pwcheck_method: auxprop
sasl_mech_list: CRAM-MD5 DIGEST-MD5

And if I use "testsaslauthd -u user -p password" I get a Success.

This is what I'm running:

cyrus-imapd-3.4.4-2.fc37.x86_64
cyrus-imapd-libs-3.4.4-2.fc37.x86_64
cyrus-imapd-utils-3.4.4-2.fc37.x86_64
cyrus-sasl-2.1.28-8.fc37.x86_64
cyrus-sasl-lib-2.1.28-8.fc37.x86_64
cyrus-sasl-md5-2.1.28-8.fc37.x86_64
cyrus-sasl-ntlm-2.1.28-8.fc37.x86_64
cyrus-sasl-plain-2.1.28-8.fc37.x86_64

SMTP Submission (port 587) with Sendmail AUTH continues to work, and that's 
using SASL and the same credentials, so the database isn't corrupted.

My clients are MacOS and iOS, if that matters.

I ran the session logging on MacOS and decoded the AUTH transaction in IMAP/S, 
and it's definitely sending just the username, no realm/domain... so no idea 
where this is creeping in.

Mail is down, and there's an angry mob outside my office...

Any assistance?

Thanks,

-Philip


--
Nic bernstein...@nicbernstein.com
https://www.nicbernstein.com

------------------------------------------
Cyrus: Devel
Permalink: 
https://cyrus.topicbox.com/groups/devel/Td95652dad981f128-M4a42971a17cb7ddc838c3a57
Delivery options: https://cyrus.topicbox.com/groups/devel/subscription

Reply via email to