Message-ID: <50F5C267.2090902@kaltenbrunner.cc>
Date: Tue, 15 Jan 2013 21:56:07 +0100
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-www@postgreSQL.org
Subject: Re: Bogus duplicate-message complaints from PG mail lists
References: <2493.1358282742@sss.pgh.pa.us>
In-Reply-To: <2493.1358282742@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-www-owner@postgresql.org

On 01/15/2013 09:45 PM, Tom Lane wrote:
> Several times over the past couple of days, I have gotten complaints
> like the one attached about duplicate message IDs.  I can see from my
> sendmail daemon's log that I sent only one copy of this, and the
> complaint is dated about twenty minutes after the fact, so I'm pretty
> sure the duplicate is not of my making.
> 
> Usually when I get this type of thing I can tell from the Received:
> lines that it's the fault of some list subscriber's MUA re-submitting
> a message to the lists.  But the Received: lines in this example and
> the last couple don't show that the message has gone anywhere outside
> postgresql.org.  So I'm thinking it's a recently-introduced glitch in
> the mail list server arrangements.

those are caused by a network issue between one of the .eu server
locations and the .eu location the listserver itself is in.
The problem is that TCP sessions will get cut off in-transmission and
both ends of the communication end up seeing different states of the
session.
In the particular cases of the "mail duplication" it is basically the
sender (makus.postgresql.org - inbound MX) getting a TCP-session timeout
after the the end of DATA in the SMTP session and the receiving
side(malur.postgresql.org - the listserver) actually got the full mail
AND acknowledged it but the sender never got the reply back.
The sender (having no ack from the receiver) retries, generating a dup...

We are working on fully diagnosing what is causing this (other parts of
the infrastructure are impacted as well just not as visible) but the
intermediate nature and the complexity(and number) of networks involved
are not helping.


Stefan


-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www