The opessl changes could be ti blame On Thu, Jun 8, 2023, 13:24 Nic Bernstein <n...@nicbernstein.com> wrote:
> 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 forhttps://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 > nic@nicbernstein.comhttps://www.nicbernstein.com > > *Cyrus <https://cyrus.topicbox.com/latest>* / Devel / see discussions > <https://cyrus.topicbox.com/groups/devel> + participants > <https://cyrus.topicbox.com/groups/devel/members> + delivery options > <https://cyrus.topicbox.com/groups/devel/subscription> Permalink > <https://cyrus.topicbox.com/groups/devel/Td95652dad981f128-M4a42971a17cb7ddc838c3a57> > ------------------------------------------ Cyrus: Devel Permalink: https://cyrus.topicbox.com/groups/devel/Td95652dad981f128-M57ca372439022235a8a52cae Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
