Jeff Lasman wrote:
> This one has me stumped.
>
> Here's the headers from a message (only the recipient address has been
> changed; nothing else):
When obfuscating addresses, please don't obfuscate the domain, but
rather just the local part.
> Delivery-date: Tue, 02 Aug 2005 17:28:02 -0700
> Received: from web60617.mail.yahoo.com ([209.73.178.185])
> by da1.ns-one.net with smtp (Exim 4.24)
> id 1E06Wi-0008Tg-SI
> for nonesuch@???; Tue, 02 Aug 2005 16:50:28 -0700
>
> But when I do a search for 1E06Wi-0008Tg-SI I only find it at 17:28:02.
>
> What am I missing?
>
> We're trying to understand the delay.
The logs would have been helpful; without them, we're just guessing.
http://exim.org/exim-html-4.50/doc/html/spec_43.html#IX2702
"At this stage, the timestamp in the Received: header line is the time
that the message started to be received. This is the value that is seen
by the DATA ACL and by the local_scan() function."
http://exim.org/exim-html-4.50/doc/html/spec_24.html#IX1904
"If this option is true, a Delivery-date: header is added to the
message. This gives the actual time the delivery was made."
So the message spent about 45 minutes between first starting to receive
the message (I'm guessing this is the time of receipt of the MAIL FROM
smtp command), and final delivery by the transport. Do you have
"log_selector = +queue_time_overall" set? If so, you should see a
QT=37m34s clause on the message's Completed log entry, to confirm this.
The most likely culprits are:
a> very slow network traffic while receiving the body of the message.
b> delays processing the ACLs. Particularly content scanning (ie:
spamassassin) in the DATA ACL.
c> temporary failures delivering the message, causing it to sit on the
queue for a while.
C would have shown up in your logs; while you didn't post them, you
probably would have noticed a temp failure, so I'm guessing that's not
it. However, just in case you missed it or didn't know what to look
for, you want to look for large DT= clauses on the => log entry for the
delivery.
Was the message very large? If so, that would cause both A and B; check
your content filter logs for more details. Especially if the message
triggered one of spamassassin's known achilles heels, such as deeply
nested multipart attachments.
- Marc
