#249 Mail server not handling duplicate messages reasonably.
Closed: Fixed None Opened 16 years ago by bruno.

The last couple of days I have been have some problems with messages sent to fedora lists. I have had messages show up multiple times. I am getting a temporary failure (deferral) and a message suggesting that some sort of duplicate detection is being triggered. My log has the following:
deferral: Connected_to_66.187.233.32_but_connection_died.Possible_duplicate!(#4.4.2)/

Since the messages are showing up multiple times on the list, I suspect that despite the temporary failure, the message is being delivered. If that is the case, then a success status should be returned, not a temporary failure. And even if the message wasn't being delivered, I would have expected a permanent failure, as the duplicate status shouldn't change.

I am not sure what starts this process. I do have occasional network congestion, so that it could be that a message gets accepted, by my server doesn't see the success status. However, once it does start, I need to manually remove the messages from the queue as it will take a couple of days for the server to give up on them.

Here is the sample headers for one such message so that you can look at the server logs on your side to see what might be happening:
Return-Path: fedora-devel-list-bounces@redhat.com
Delivered-To: bruno@wolff.to
Received: (qmail 24686 invoked from network); 23 Nov 2007 09:01:08 -0000
Received: from unknown (HELO hormel.redhat.com) (209.132.177.30)
by wolff.to with SMTP; 23 Nov 2007 09:01:08 -0000
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP
id 5F3D673B99; Fri, 23 Nov 2007 04:01:07 -0500 (EST)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
lAN912x8016965 for fedora-devel-list@listman.util.phx.redhat.com;
Fri, 23 Nov 2007 04:01:02 -0500
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAN912bN000706
for fedora-devel-list@redhat.com; Fri, 23 Nov 2007 04:01:02 -0500
Received: from wolff.to (wolff.to [66.93.197.194])
by mx3.redhat.com (8.13.1/8.13.1) with SMTP id lAN90aMH025149
for fedora-devel-list@redhat.com; Fri, 23 Nov 2007 04:00:36 -0500
Received: (qmail 4102 invoked by uid 500); 22 Nov 2007 14:13:40 -0000
Date: Thu, 22 Nov 2007 08:13:40 -0600
From: Bruno Wolff III bruno@wolff.to
To: Richard Hally rhally@mindspring.com
Message-ID: 20071122141340.GA2857@wolff.to
References: 20071120140550.GA20367@dspnet.fr.eu.org
20071120082647.137221b6@weaponx
20071120145119.GA26405@dspnet.fr.eu.org
1195578414.3568.58.camel@localhost.localdomain
20071120184133.GA51420@dspnet.fr.eu.org
20071121151510.GA21330@wolff.to 4744B768.301@mindspring.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 4744B768.301@mindspring.com
User-Agent: Mutt/1.4.2.1i
X-RedHat-Spam-Score: -0.732
X-Scanned-By: MIMEDefang 2.58 on 172.16.48.32
X-loop: fedora-devel-list@redhat.com
Cc: Development discussions related to Fedora fedora-devel-list@redhat.com
Subject: Re: WTF? Inaccessible bug reports?
X-BeenThere: fedora-devel-list@redhat.com
X-Mailman-Version: 2.1.5
Precedence: junk
List-Id: Development discussions related to Fedora
<fedora-devel-list.redhat.com>
List-Unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-devel-list,
fedora-devel-list-request@redhat.com?subject=unsubscribe
List-Archive: https://www.redhat.com/archives/fedora-devel-list
List-Post: fedora-devel-list@redhat.com
List-Help: fedora-devel-list-request@redhat.com?subject=help
List-Subscribe: https://www.redhat.com/mailman/listinfo/fedora-devel-list,
fedora-devel-list-request@redhat.com?subject=subscribe
Sender: fedora-devel-list-bounces@redhat.com
Errors-To: fedora-devel-list-bounces@redhat.com
Status: RO
Content-Length: 580


I looked into this some and it appears to probably just be a timeout issue. I am am sure on whose side the timeout is occurring. I had previously had it set on my end to 20 seconds (as I don't send very large messages) and hadn't been seeing problems with any other places.
And I hadn't seen anything with redhat servers until recently. But if that value was tight and either the load increased or some change (e.g. greet delay) increased the time needed to accept the message, what I am seeing could be the result. I have increased the timeout and will report back on whether or not that fixed the problem.

The problem appears to have been resolved by increasing the timeout on my end.
I don't know for sure, but I expect that Redhat's mail server either had a greet delay set to be the same as my remote timeout (20 seconds) or a significant delay was occurring between when my server finished sending the data part of messages and when the mail server acknowleged responsibility for the message.

Login to comment on this ticket.

Metadata