similar to: Authentication error with corrections

Fellow Dovecot'ers. I tried something tonight that I should have done a while back: Turned on verbose logging in the authentication section. I'm still unable to get the mail client I'm experimenting with (Pegasus) to complete a pop3s connection, in that I still get an indication of a failed password. However, at least I'm a little closer to understanding the failure itself.

Fellow users, This is just a heads-up to let the list know that I'm still unable to get ANY sort of pop3 or pop3s authentication to work with Dovecot. Just as a sanity check, I set up an entirely separate system, running FreeBSD 6.1 production, postfix 2.3, and Dovecot 1.0rc2, as a testbed. I got the exact same problem that I had with the NetBSD 3.0 production server, specifically that

Fellow Dovecot'ers, I've -almost- got Dovecot completely functional, and I will add that it works just fine for non-authenticated POP3. The problem begins when I try to use authentication for same against the system's /etc/passwd section. This is the error message that comes up in /var/log/maillog Jul 9 21:14:10 featherweb dovecot: auth(default): pam(kyrrin at

Hi, Petar, For whatever reason, I didn't see your most recent reply until I checked the web archives. To answer your questions... Is my dovecot running chrooted? Not that I know of. However, the option to (apparently) decide this is confusing at best. Here is what I have entered. # chroot login process to the login_dir. Only reason not to do this is if you # wish to run the whole

How does one go about generating a local password database for apop authentication? Or can it simply run against /etc/passwd, using a PAM entry? (I forgot to append this to my last message... sorry...). Thanks much. -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner & Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m "If

pop3 and pop3s under protocolos but still seeing the imap-login process, it sounds like your dovecot install isn't reading the proper configuration = file (or at least the one you're editing). Maybe that's why these changes = don't seem to do anything? --=20 Jeff Graves, MCSA Image Source, Inc. 508.966.5200 x31=20 www.image-src.com -----Original Message----- From: dovecot-bounces

Fellow techies, OK... This is going to go down as one of those "D'Oh!" moments in the world of computers. Boy, do I feel dumb... In short: I found the problem. One miserable little line in 'dovecot.conf' called 'auth_default_realm =.' I had this set to 'bluefeathertech.com,' thinking it was necessary to do so. I was wrong, at least for my environment,

Fellow dove-users, Just a note to say that Dovecot 1.0rc7 is working very well indeed, supplying SPOP3, regular POP3, and TLS/SASL services on FreeBSD 6.1 Production, in conjunction with Postfix 2.3.2. I have authentication methods PAM and passwd in use. Keep the peace(es). -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner & Head Hardware Heavy, Blue Feather Technologies --

Hi, gang, There have been numerous postings, scattered across various Internet forums (including this one), about problems encountered using Veritas Backup Exec 8.6 and higher with Samba-sourced shares from *nix servers. In my particular case, I have a Windows NT Server 4.0-based backup system, which is supposed to be able to back up the other Windows systems on the LAN, plus several SPARC boxes

Fellow Samba folk, I'm in the process of resurrecting one of my servers with FreeBSD 6.0/Production, and Samba 3.x (I installed the FreeBSD-obtained package). I'm using 'domain' for the security mode, and the Samba server was successfully joined to my domain. It -almost- works. I can see the share from my Windows 2000 system, and browse it. However, I cannot write to it. I keep

Fellow samba folk, This one's making me want to tear out what little hair I have left. THE *NIX PLATFORM: FreeBSD 7.0-RELEASE, Samba 3.3.8. THE ENVIRONMENT: Small domain, Windows 2003 servers and XP-pro based workstations. The FreeBSD server is a member server in the domain, so at least that works. THE SYMPTOMS: This is bizarre. I can, using mount_smbfs on the FreeBSD side, easily

Good day, gang, Chris McKeever was kind enough to write back to me over the weekend regarding the problems I'd experienced in using Backup Exec 8.x and 9.x to connect to Samba shares on a NetBSD system. Between his comments and my direct experience, I've only found ONE combination that will work, and that is: NetBSD 1.6, Samba 2.2.8a, and Backup Exec 8.6. If you take NetBSD up to 1.6.1,

Fellow Samba-shakers, I've run into an odd problem, and I'm seeking the advice of anyone who has implemented Veritas Backup Exec 8.6 or 9.0, on an NT 4.0 server platform, to perform backups of NetBSD 1.6x systems via Samba file shares. Said problem did NOT manifest itself until I tried using Samba 3.0.0. I have jumped back to 2.2.8a, since that's the last version that was known to

Fellow samba folk, Please disregard my earlier message. I have solved the problem, and it appears to have been a combination of things. First, somehow (I have no idea how), the Samba package must have gotten corrupted during installation. I cleaned up the mess, reinstalled, and had much better results. Second issue: I followed the instructions at this link, Section 2.6, VERY carefully, to

Fellow samba dancers, Here's my situation: I've got a NetBSD (1.6) box running smoothly enough with the most recent stable Samba release (2.2.7a). I have no problems whatsoever browsing, reading, and writing files from NT boxes to the shared directory using File Manager or Explorer. Our NT server is a PDC, and has Veritas Backup Exec 8.6 and a tape library on it. This serves as the

Fellow samba dancers, Before I lose it, and teach our server to fly, I think it best if I ask the experts. THE SETUP: FreeBSD 7.0-Release, i386 platform (Proliant ML530 to be exact), Samba version 3.0.31,1. Windows domain based on Windows 2000 Advanced Server, with mixed NT-style and Active Directory style security. Domain name is FREEDOM_RIDGE, two active-directory domain controllers called

Hello! Upgrading manual tells that authdb [NSS module was removed][1] some time ago. [1]: https://wiki2.dovecot.org/Upgrading/2.3#line-100 > userdb nss was removed. Use userdb passwd instead. Can this change be reverted? I'd like to use only libnss_sss.so.2 as dovecot userdb source. It's also essential for me to enable files backend in nsswitch.conf so the system could use local

I use LDAP right now, but local cached sssd queries are much faster and reliable. On July 15, 2019 6:49:18 AM GMT+03:00, Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > > >On 15/07/2019 02:54 Eugene via dovecot < dovecot at dovecot.org> wrote: > > > >Hello! > > >Upgrading manual tells that authdb [NSS module was removed][1] some >time ago. >

Gedalya-san Thank you for the information. It seems to be difficult... morikawa -----Original Message----- From: dovecot [mailto:dovecot-bounces at dovecot.org] On Behalf Of Gedalya Sent: Thursday, October 29, 2020 1:17 PM To: dovecot at dovecot.org Subject: Re: dovecot quota-warning detection mail Aha. Then it's not a straightforward case of just adding the domain name to the same

Hi there, I run a system that has a lot of virtual users. We invoke deliver from exim and pass the directory to deliver into using the HOME environment variable, so deliver doesn't do any database lookups during the delivery process. The exim pipe environment is described at http://exim.org/exim-html-current/doc/html/spec_html/index.html#toc0239, but basically I'd like to know the domain