On 04/11/2013 03:10 PM, Charles Sprickman wrote:
On Apr 11, 2013, at 5:02 PM, Tom Collins wrote:


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, 
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/xxxx, address=x...@bway.net, fullname= 
'xxxx', maildir=<null>, quota=<null>, 
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. :)



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?



Have you considered migrating to qmail-toaster? That should be a pretty straight forward migration (qmailtoaster-plus includes backup and restore scripts that are useful for migrating). There are a few vpopmail database changes between 5.4.7 and 5.4.33, but that shouldn't be very difficult do. The qtp-convert script handles the changes from 5.4.17 to 5.4.33.

While dovecot will be replacing courier as the stock IMAP service in the near future, there are instructions on the wiki for doing this conversion: http://wiki.qmailtoaster.com/index.php/Replacing_Courier_IMAP_with_Dovecot_IMAP

With the addition of spamdyke (qtp-install-spamdyke), you may find yourself not needing to front-end your new qmail with postfix. Spamdyke is a highly effective and extremely efficient anti-spam tool. It eliminates 90+% of spam without even receiving the whole message. It's truely amazing, and will lighten the load on your mail server as well. Unfortunately spamdyke is only available with the qmail mta at this time (not postfix or exim). If I had to pick one of spamdyke or spamassassin, I'd pick spamdyke. Fortunately though, with QMT you can use both. :)

I should add that many people use QMT as a front-end to Exchange. No surprise there really though.


Disclaimer: I'm the project lead for QMT, so I might be biased. ;)

-Eric 'shubes'


Reply via email to