[Dovecot] Pop3s duplicates

[Timo Sirainen]

Sorry a late reply, reading older mailing list mails only now..

On Tue, 2006-09-05 at 12:20 +0100, Mark Adams wrote:
> Hi,
> 
> dovecot 1.0 rc6
> 
> Can someone please advise on my interpretation of the following logs,
> Users are reporting duplicate email coming through to their inbox.
> (user at domain replaced actual username and domain) There are also reports
> of the connection seemingly freezing whilst the emails are being
> downloaded (pausing at a certain amount of kB then continuing after a
> minute or 2).

In rc6 the SSL hangs were supposed to be fixed, so I can't really think
of why these freezes would happen..

> info: pop3-login: Login: user=<user at domain>, method=PLAIN, rip=89.192.*.**, lip=172.16.22.10, TLS
> info: POP3(user at domain): Disconnected top=0/0, retr=4/183443, del=0/313, size=83779942
> info: pop3-login: Login: user=<user at domain>, method=PLAIN, rip=89.192.*.**, lip=172.16.22.10, TLS
> info: POP3(user at domain): Disconnected top=0/0, retr=3/183443, del=0/322, size=84201570
> 
> In the first instance the user downloaded 4 emails totalling 183443
> bytes leaving 313 messages on the server. (outlook 2003 set to leave a
> copy of messages on the server)
> 
> second instance user downloaded 3 emails, exactly the same amount of
> bytes and left 322 messages on the server.
> 
> Does this mean the users connection was interrupted when downloading the
> original emails and they attempted to be sent again a second time?  how
> could it be that there are 9 emails left on the server if only 3 extra
> were downloaded?

I changed those log messages recently (I think after rc7 release) to
show disconnections and proper logouts separately. There you'd see which
one happened.

I guess the above means that in first case the client started
downloading 4th message before the connection died. In the second case
the client downloaded the 3 messages but connection died before it could
continue.

I think the retr bytes normally show only complete messages' bytes
because the kernel reads it completely and buffers it internally before
sending.

So yea, your problem is that the connections die too early. Did you yet
figure out what caused them?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20061009/932a8c61/attachment.pgp