[vchkpw] [SPAM] lastauth troubles, old version

2013-04-11 Thread Charles Sprickman
It's been some time since I've had to dig into any vpopmail issues as we have a 
box that's been frozen in time for years.  It's quite the frankenbox at this 
point and I'll be having to get myself up to speed in the coming months to deal 
with a move to new hardware, moving to dovecot from courier, and fronting the 
whole qmail mess with postfix.

So I decided to start small and verify I can still rebuild the current vpopmail 
version we run (5.4.7) in a VM and alter a few options.

I opted to enable the last login function.  It was turned off long ago to 
alleviate some db load, but that's no longer an issue for us.  I've rebuilt 
5.4.7 with --enable-auth-logging but I'm not seeing all logins show up in the 
lastauth table.  We use courier (4.0.6) and authdaemond (0.58) with vpopmail 
auth enabled.

In my testing, I tried a pop3, pop3s, imap, and imaps login and found no errors 
logged and no logins show up in the lastauth table.  To complicate matters, I 
do see a handful of users showing up in the table, but I can't find any common 
criteria here - some of these users are pop, some are imap.

I feel like I've probably forgotten some piece of this puzzle, any hints?  How 
can I debug why the logins are not being logged?

Thanks,

Charles
!DSPAM:516705a134141703739669!



Re: [vchkpw] [SPAM] lastauth troubles, old version

2013-04-11 Thread Tom Collins
Charles,

QmailAdmin will update lastauth (as least the file in the user's directory) as 
well.  I know that on my current system, pop3 and pop3s update the file (using 
qmail's POP server) but IMAP does not (using dovecot).

-Tom


On Apr 11, 2013, at 1:47 PM, Charles Sprickman wrote:

 It's been some time since I've had to dig into any vpopmail issues as we have 
 a box that's been frozen in time for years.  It's quite the frankenbox at 
 this point and I'll be having to get myself up to speed in the coming months 
 to deal with a move to new hardware, moving to dovecot from courier, and 
 fronting the whole qmail mess with postfix.
 
 So I decided to start small and verify I can still rebuild the current 
 vpopmail version we run (5.4.7) in a VM and alter a few options.
 
 I opted to enable the last login function.  It was turned off long ago to 
 alleviate some db load, but that's no longer an issue for us.  I've rebuilt 
 5.4.7 with --enable-auth-logging but I'm not seeing all logins show up in 
 the lastauth table.  We use courier (4.0.6) and authdaemond (0.58) with 
 vpopmail auth enabled.
 
 In my testing, I tried a pop3, pop3s, imap, and imaps login and found no 
 errors logged and no logins show up in the lastauth table.  To complicate 
 matters, I do see a handful of users showing up in the table, but I can't 
 find any common criteria here - some of these users are pop, some are imap.
 
 I feel like I've probably forgotten some piece of this puzzle, any hints?  
 How can I debug why the logins are not being logged?
 
 Thanks,
 
 Charles
 
 


!DSPAM:5167091c34145934024422!



Re: [vchkpw] [SPAM] lastauth troubles, old version

2013-04-11 Thread Charles Sprickman
On Apr 11, 2013, at 5:02 PM, Tom Collins wrote:

 Charles,
 
 QmailAdmin will update lastauth (as least the file in the user's directory) 
 as well.  I know that on my current system, pop3 and pop3s update the file 
 (using qmail's POP server) but IMAP does not (using dovecot).

Interesting.  Most of our users don't know about qmailadmin - they do password 
changes and spam settings inside our webmail.

I also just tried logging into qmailadmin with a test account, and still no 
lastauth entry.

Odd how random this seems.  I noticed that even the users that have ended up 
with lastauth entries are only getting some of their logins updated - for 
example, I might see someone with a lastauth timestamp of 4:30, but then see a 
dozen or more logins after that in the mail log.

I've enabled more logging in authdaemond (which I assume through the vchkpw 
module is where the last auth logging should be taking place), but I don't see 
anything particularly odd:

Apr 11 18:08:16 xena pop3d-ssl: Connection, ip=[x.x.x.x]
Apr 11 18:08:16 xena authdaemond: received auth request, service=imap, 
authtype=login
Apr 11 18:08:16 xena authdaemond: authvchkpw: trying this module
Apr 11 18:08:16 xena authdaemond: authvchkpw: sysusername=null, sysuserid=90, 
sysgroupid=90, homedir=/home/vpopmail/domains/bway.net/2/, 
address=x...@bway.net, fullname= '', maildir=null, quota=null, 
options=disablewebmail=0,disablepop3=0,disableimap=0
Apr 11 18:08:16 xena authdaemond: password matches successfully

Not having much luck finding a vpopmail changelog that dates back to 5.4.7. :)

Charles

 -Tom
 
 
 On Apr 11, 2013, at 1:47 PM, Charles Sprickman wrote:
 
 It's been some time since I've had to dig into any vpopmail issues as we 
 have a box that's been frozen in time for years.  It's quite the 
 frankenbox at this point and I'll be having to get myself up to speed in the 
 coming months to deal with a move to new hardware, moving to dovecot from 
 courier, and fronting the whole qmail mess with postfix.
 
 So I decided to start small and verify I can still rebuild the current 
 vpopmail version we run (5.4.7) in a VM and alter a few options.
 
 I opted to enable the last login function.  It was turned off long ago to 
 alleviate some db load, but that's no longer an issue for us.  I've rebuilt 
 5.4.7 with --enable-auth-logging but I'm not seeing all logins show up in 
 the lastauth table.  We use courier (4.0.6) and authdaemond (0.58) with 
 vpopmail auth enabled.
 
 In my testing, I tried a pop3, pop3s, imap, and imaps login and found no 
 errors logged and no logins show up in the lastauth table.  To complicate 
 matters, I do see a handful of users showing up in the table, but I can't 
 find any common criteria here - some of these users are pop, some are imap.
 
 I feel like I've probably forgotten some piece of this puzzle, any hints?  
 How can I debug why the logins are not being logged?
 
 Thanks,
 
 Charles
 
 
 
 
 
 


!DSPAM:5167194334141264340400!