Hello list,
We've encountered a very strange event on one of
our courier-imap/authlib installations. Basically it appears
that the content of one user mailbox (account2)
was being retrieved by a pop3 session of a different user (account1).
Both users were using pop3 exclusively, account2 using a
"leave on server" optiont, account1 didn't, so account1 downloaded
all the emails in account2's maildir at that time, emptying account2's
maildir afterwards.
The log file entries we suspect for the actual downloads.
13:19:26 pop3d: LOGIN, user=account1,
<other requests by different accounts>
13:19:26 pop3d: LOGIN, user=account2,
<other requests by different accounts>
13:19:26 pop3d: LOGOUT, user=account2, top=0, retr=0, rcvd=18,
sent=1174, time=0
<other requests by different accounts>
13:20:12 pop3d: LOGOUT, user=account1, top=0, retr=27144647, rcvd=1254,
sent=27505785, time=46
We're running courier-imap 4.1.0 and courier-authlib 0.58 (Changelog
descriptions
of later versions do not seem to contain anything that might explain the
above
behaviour), on a FreeBSD 5.4 machine:
authlib
./configure --prefix=/courier --with-pgsql-libs=/usr/local/lib
--with-pgsql-includes=/
usr/local/include --with-makedatprog=/courier --with-mailuser=root
--without-socks
imap
./configure --prefix=/courier --with-pgsql-libs=/usr/local/lib
--with-pgsql-includes=/
usr/local/include --without-socks --without-stdheaderdir
The authentication backend is provided by a PosgreSQL DB (7.4.X) which
defines an SQL view that delivers the DB table fields just as
courier-authlib
needs them. The maildir returned is definitely a different one
for each account and we would discount the possibility of any wrong
data was being returned by the DB server (login and password being part
of the same DB row), we've also tested this with a large number of
requests...
Courier-imap and the Postgres DB both run as (seperate) LVS
cluster groups.
Any clues to what could have caused this problem would be greatly
appreciated.
Given that we're handling millions of requests
per day, and that we've never had reports of something like
that so far, it's certainly not a common problem... let alone a
reproduceable bug.
TIA
T Jacob
p.s.: I can provide more details of setup and/or config files if
required....
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
