> >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 > > Why exactly do you suspect account1, instead of any one of the "other > requests by different accounts"?
Well, account1 retrieved the messages in the mailbox of account2 during that POP3 session, this has been established from the logs of account1's fetchmail installation. However, that the fact that account2 also made a POP3 request at the same time on the same POP3 server has anything to do with this event, is just an assumption on my part. Given that both accounts do their requests in rather large intervals, and that requests are loadbalanced over a number of servers, a quasi-simultaneous request on the same machine isn't all that likely. > In any case this cannot happen for the very simple reason of how POP3 > works. In POP3, message files are physically deleted just before the > session logs out. Here, account1's messages would end up being deleted at > 13:20:11, at the earliest, so when account2 logged on, all the messages > would've still been in the account, if your theory that account1 and > account2 somehow opened the same maildir was really what happened. Sure, but remember that account2 was using (Outlook's) "leave on server" option, so account2 already saw those messages before, and consequently didn't download any (as indicated by retr=0, right?). The account2 people only learned about this event when the account1 contacted them saying that they received their messages, that is, also received their messages... So for some reasons account1 at least got access to the wrong maildir I think, just this once... Thomas p.s.: there is no connection between the account1 and account2 people, they are as mystified as us about the event... ------------------------------------------------------------------------- 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
