Small emails being delayed

[#1]

Has anyone noticed this?
It looks like small emails (a few lines) are being delayed by several hours whilst larger emails (around a page) go through relatively quickly. 

I don't know what is causing this. At the beginning I was wondering if the system was overloaded (I was not getting emails I was expecting) but in fact, after a number of test using external and internal email accounts, I realised that the size of the message played a critical role in determining if I get the email or not.
I am convinced I will get the other emails tomorrow morning but still, this is really quite strange and not ideal IMHO 

[#2]

If you could raise a ticket with the headers of one of the delayed emails on I'll get this looked at for you.

[#3]

If you can PM me the headers then I'd be happy to take a look at this now.
Are the emails being sent via relay.plus.net and where are they being sent to?

[#4]

This one seems to have been hanging around for a while:

Envelope-to: xxx@yyy.plus.com
Delivery-date: Tue, 07 Aug 2007 14:39:44 +0000
Received:  by fhw-sunmxcore02.plus.net with spam-scanned (PlusNet MXCore v2.00) id 1IIQDn-0001Cd-RB 
	  for xxx@yyy.plus.com; Tue, 07 Aug 2007 14:39:44 +0000
X-Daemon-Classification: INNOCENT
Received: from ptb-relay01.plus.net ([212.159.14.212])
	  by fhw-sunmxcore02.plus.net with esmtp (PlusNet MXCore v2.00) id 1IIOHr-0003Y1-Tt 
	  for xxx@yyy.plus.com; Tue, 07 Aug 2007 12:35:48 +0000
Received: from [192.168.101.41] (helo=pih-community02.plus.net)
	 by ptb-relay01.plus.net with esmtp (Exim) id 1IIO9T-0000oE-IH
	for xxx@yyy.plus.com; Tue, 07 Aug 2007 13:27:07 +0100
Received: from www-data by pih-community02.plus.net with local (Exim 4.63)
	(envelope-from <www-data@pih-community02.plus.net>)
	id 1IIO9T-0000xV-Ej
	for xxx@yyy.plus.com; Tue, 07 Aug 2007 13:27:07 +0100
To: xxx@yyy.plus.com
Subject: Topic reply: Posting in English Language only please
From: "Forum" <community@plus.net>
Date: Tue, 07 Aug 2007 12:27:07 +0000
Message-ID: <8e01d8a2cd16c3a61c5afcb0f5f131e4-m5172@plus.net>
X-Mailer: SMF
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="SMF-c7e99a44ecc2ce5480ea96a96e835679"
Content-Transfer-Encoding: 7bit
X-PN-VirusFiltered: by PlusNet MXCore (v4.00)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Tue Aug  7 14:39:44 2007
X-DSPAM-Confidence: 0.7614
X-DSPAM-Improbability: 1 in 320 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Factors: 27,
	Received*www, 0.00229,
	Url*net/forum/index, 0.01000,
	Url*net/forum/index, 0.01000,
	Url*topicseen#new, 0.01000,
	Url*topicseen#new, 0.01000,
	topic+by, 0.01000,
	topic+by, 0.01000,
	Subject*Topic+reply, 0.01000,
	discrimination+and, 0.01000,
	discrimination+and, 0.01000,
	posted+but, 0.01000,
	posted+but, 0.01000,
	Url*php?action=notify, 0.01000,
	Url*php?action=notify, 0.01000,
	More+replies, 0.01000,
	More+replies, 0.01000,
	watching+by, 0.01000,
	watching+by, 0.01000,
	topic+you, 0.01000,
	topic+you, 0.01000,
	Url*//community, 0.01000,
	Url*//community, 0.01000,
	Received*Aug+2007, 0.99000,
	Received*Aug+2007, 0.99000,
	notifications+until, 0.01000,
	notifications+until, 0.01000,
	Unsubscribe+to, 0.01000

[#5]

Thanks jelv. I could do with more examples if anyone has them.

[#6]

Interesting, after a few tests it looks like that most of the delay are caused by the PN SMTP relay called "ptb-relay01.plus.net" and it is also the very same machine where your message got stuck...
Here are the headers of test I did today.

Envelope-to: xxx@yyy.plus.com
Delivery-date: Tue, 07 Aug 2007 16:20:57 +0000
Received: from server26.ukservers.net ([217.10.138.203])
	  by pih-sunmxcore18.plus.net with esmtp (PlusNet MXCore v2.00) id 1IIRnl-0007Aj-FL 
	  for xxx@yyy.plus.com; Tue, 07 Aug 2007 16:20:57 +0000
Received: from mx-26.ukservers.net (server26.ukservers.net [10.0.17.203])
	by server26.ukservers.net (Postfix) with ESMTP id 35C742B34F6
	for <xxx@yyy.plus.com>; Tue,  7 Aug 2007 17:20:36 +0100 (BST)
Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212])
	by mx-26.ukservers.net (Postfix mx-26) with ESMTP id 1959F246F81
	for <xxx@yyy.plus.com>; Tue,  7 Aug 2007 17:20:35 +0100 (BST)
X-UKServers-IP: 212.159.14.212
Received: from [80.229.XX.YYY] (helo=zzz)
	 by ptb-relay01.plus.net with esmtp (Exim) id 1IIRSu-000707-I2
	for xxx@yyy.plus.com; Tue, 07 Aug 2007 16:59:24 +0100
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Date: Tue, 07 Aug 2007 16:59:23 +0100
Message-ID: <op.two5c9gsijv7at@zzz>
User-Agent: Opera Mail/9.20 (Linux)

Note however that today it does not seem to be affected by the size of the message (I suspect in the end what mattered was which relay took responsability for transmitting the message).

[#7]

Note to the PN support team: I also created a PN support case:  22533810

[#8]

In jelv's example I read the headers to show the delay being on fhw-sunmxcore02.plus.net and not the relays.
It's not helping that some of the servers have a timestamp that's out by an hour (there's a task with our ops team to fix this).

[#9]

Idea:
I suspect some of these delays could be "normal" (machine overloaded for some reason). Now looking at the statistics panel it is very difficult to say because we don't know how many message per hours these machines are processing.
So I wonder if it would not be an idea to try and express the MX statistics in terms of expected delay for incoming and outgoing MX traffic.
I know this will only give an average idea as typically this is influenced by "is the machine at the other end responding?" but at least it would be better than "MX queue = 1k" which to me does not mean a lot...