Works for me with kmail 1.10.1 (kde 4.1.2). I've been using pop3 with kmail for a long time now, configured not to leave messages on server, but I've never seen this behavior.

As I thought I implied in the original report, I am unsure whether this is a Kmail bug or a Comcast bug. (or something about the interaction between them)

I'm primarily filing the bug (after checking the existing bugs and not finding something that already matched my symptoms) to get a more definitive answer about where my problem might be.

ART

Arthur, thanks for filing this very detailed bug report. Unfortunately, I fear this issue is going to be very tricky to figure out.

As stated in comment #1, this is not a common issue, so its not a straight-forward KMail bug. However, it really isn't clear at the moment whether it is some more obscure KMail bug, and if so, what is triggering it.

One possible theory you mention in the original report is that KMail is not always deleting emails from the server when it downloads them. It would be great if you could catch an email still on the server after KMail had downloaded it (using some other program/webmail). In order to know how feasible this is to do, could you please tell us roughly how often this bug happens to you.

George, it is very random.  Some times I can go for several weeks with no duplicates, then I will get several in the same day.  The number of repeats is also quite random - however MOST of the time I only get two copies, sometimes three, rarely 3 or more... Thus most times it appears that by the time I realize I'm getting duplicates, the problem has already fixed itself :-(

It was a very rare coincidence the other day that I was reading messages and realized a duplicate had come in while I was reading the first message so that I could tell that I was indeed getting one copy per mail retrieval, not multiple copies on a single retrieval.

To give a rough idea, looking through my trash folder, I found 7 or 8 pairs between today (10/18) and 10/07 when I had one message that appeared 7 times! I also had one other message that appeared twice, out of 17 messages that came in that day... (One of which was a test message from Comcast, that worked fine...)

Also as a FWIW, I can semi-confirm that the duplicates ARE identical - I copied both instances of a pair to files, with the display set to "show all headers" and ran xxdiff on the two files - NO differences found.

This is the relevant part of one of the headers (e-mails changed to protect against bots...):
------------
Received: from imta24.westchester.pa.mail.comcast.net ([76.96.62.55])
          by sccrmxc13.comcast.net (sccrmxc13) with ESMTP
          id <20081015191753s1300io9rae>; Wed, 15 Oct 2008 19:17:53 +0000
 X-Originating-IP: [76.96.62.55]
 Received: from hearth.quonix.net ([208.72.236.150])
        by IMTA24.westchester.pa.mail.comcast.net with comcast
        id T7Ht1a01D3FNY5c0Q7HtyS; Wed, 15 Oct 2008 19:17:53 +0000
 X-Authority-Analysis: v=1.0 c=1 a=MCUsTonn8BIA:10 a=WeEW8HKZshgA:10
 a=UziJOSUxBaIA:10 a=FQOYHg34AAAA:8 a=IWZuQ4UhiMDIw4bLdk4A:9
 a=TULZalrMUiPrSGFYZs0A:7 a=cC9ZfW0U8RF7CdkLRJJ51xdLhS8A:4 a=qHJQv4VtUmgA:10
 a=DPR1KcX2SjsA:10 a=m7A19GJZz-kA:10 a=sNEyDEdYjLsA:10
 Received: from hearth.quonix.net (localhost [127.0.0.1])
        by hearth.quonix.net (8.14.0/8.14.0) with ESMTP id m9FJJKpU002904
        for <ME>; Wed, 15 Oct 2008 15:19:20 -0400
 Received: (from nobody@localhost)
        by hearth.quonix.net (8.14.0/8.14.0/Submit) id m9FJJK9W002903;
        Wed, 15 Oct 2008 15:19:20 -0400
 X-Authentication-Warning: hearth.quonix.net: nobody set sender to <sender> using -f
 To: <Me>
 Subject: Hearth.com Forum New Post: Log splitter pics ?..?..?
 User-Agent: ExpressionEngine 1.6.3
 Date: Wed, 15 Oct 2008 15:19:20 -0400
 From: "Hearth.com Forum Message" <sender>
 Reply-To: "sender" <sender>
 X-Sender: <sender>
 X-Mailer: ExpressionEngine 1.6.3
 X-Priority: 3 (Normal)
 Message-ID: <48f6423881402@<sender>>
 Mime-Version: 1.0
 Content-Type: text/plain;
  charset=utf-8
 Content-Transfer-Encoding: 8bit
-----------------
I don't claim to be an expert, but my understanding is that "sccrmxc13" is my local mail server, and "imta24.westchester.pa.mail" is one of Comcast's main "internet cloud" connection machines.  If the problem had been a burp in a machine that had been further up, I would have seen different time-stamps and / or message ID's on the transfers into Comcast, or between their servers. There doesn't seem to be a timestamp on my system getting the message from the server so that is harder to measure.

ART

Well, soon as I say it's random, I get an instance...  I checked my box, and found 4 iterations of the same message - went immediately to the webmail interface of the Comcast site, and found the SAME message still sitting in my inbox on the site!

I would definitely say that it was a question of getting lucky and snagging the bug in the act.

In order to attempt to preserve whatever evidence might be there, I created a custom folder on the Comcast site and moved the message over to it.

I then used the "view source" function to look at the headers, and copied them from the browser window into a text file on my system, and did the same with one of the messages in my inbox.  Running xxdiff on the two files, showed some differences, but nothing I'd see as significant - added white space in some lines, which I'd consider likely to be artifacts of the file creation process.  There were also a few added lines at the beginning and end of the headers that appeared to be added by my system either as part of the scanning by Spamassassin and Bogofilter or by Kmail itself.

What would you like me to do as a next step?

Arthur,
It sounds like KMail is at fault here from your last comment. I'm going to pass this bug on to the KMail developers now, so I guess they will ask you for any more information they might need.

*** Bug 184757 has been marked as a duplicate of this bug. ***

hi,

as i just reported this to the kubuntu bug tracking system (https://bugs.launchpad.net/bugs/576883), i experience about the same thing in KDE 4.4.2:

i've configured kmail (1.13.2, package 4.4.2-0ubuntu5) to leave mail on the POP3 server for a few days and check every minute. this has worked ever since for me. but since the upgrade, kmail fetches mails over and over again from the server.

the strange thing is: it does end eventually. not all mails are fetched repeatingly, but the number decreases with every check. this morning i just started kmail and watched: 14 original new mails were on the server (not counting spam which is already filtered out by crm114 at this point, but it affects spam as well, of course). after they were fetched, kmail got 13 of them a second time, 11 a third time, 9 a fourth ... when it was down to 5 (old) new mails, no more duplicates were downloaded. from this point on, kmail runs for hours without any issues.

this is how kmail behaves after every new start here.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: kmail 4:4.4.2-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Fri May  7 10:33:06 2010
EcryptfsInUse: Yes
ProcEnviron:
 LANGUAGE=de_DE:de:en_GB:en
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: kdepim

Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.