30 min inbound e-mail delivery delays

[#1]

I'm seeing 30 min delays from e-mail first entering the Plusnet network to the mail being available by POP3. This is for a hosted domain with default (untouched) MX settings. The headers indicate that it has not been through the Ironport system and that there is only a single hop.
Service status for e-mail is currently 'green' - I haven't seen any Xmas excuses yet.
Does that mean that a 30-min latency within the Plusnet e-mail infrastructure is acceptable ?

[#2]

Got headers?
B.

[#3]

not a lot left after identity redaction. Does this tell you anything ?
[tt]From - Thu Dec 17 23:22:16 2009
X-Account-Key: DELETED
X-UIDL: DELETED
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                               
Return-path: <DELETED>
Envelope-to: DELETED
Delivery-date: Thu, 17 Dec 2009 22:48:13 +0000
Received: from [DELETED] (helo=DELETED.de)
  by inmx04.plus.net with esmtp (PlusNet MXCore v2.00) id DELETED
  for DELETED; Thu, 17 Dec 2009 22:48:13 +0000
Received: from REST DELETED[/tt]

[#4]

Not really - would have been interesting to see the hostname and date/time after the second Received: header.
Is your account set up to avoid the Ironport boxes (i.e. all spam filtering turned off?) or is it set for SMTP delivery?
B.
EDIT:  the reason the sending hostname/IP is useful is that it may appear on the Ironport Senderbase reputation filter.  this could cause the initial send of the message to the PN mail servers to fail with a temporary error (451?)  30 minutes sounds like a possible retry timeout for the initial sending server after which the message would likely be accepted normally.

[#5]

I have spam filtering turned off and delivery is POP3, not SMTP. That mail should never be seen by the Ironport system - a fact confirmed by the missing Ironport headers [? it's not like that Google system they dumped is it ? The one where your e-mail got delayed for scanning 'for the greater good' whether you wanted spam-filtering or not !]. Is there still a reason to know the sending host ? The timestamp is still the same.

[#6]

We're not seeing widespread reports of this and our monitoring isn't showing anything. Can you update your ticket with the *full* headers of the delayed email so we can take a look at what's going on.