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.