Long Mail Transit Time
Can anyone help to explain why the mail transit (enqueue to dequeue) takes so long to complete according to imslog.pl?
Is this a network issue or a MTA issue?
Message delays (time from enqueue to dequeue):
Channel<2 sec <10 sec <1 min <5 mins <1 hour >1 hourMax
-- - - - - - - -
ims-ms0.1%0.1%0.1%0.3%3.1%96.1% 17.45 hours
reprocess0.0%0.0%2.9%0.0%14.3%82.9% 13.19 hours
tcp_local0.0%0.0%50.0%0.0%0.0%50.0% 6.35 hours
Message transit times
Time from enqueue to dequeue, top 20 hosts by total transit time):
Host<2 sec <10 sec <1 min <5 mins <1 hour >1 hourMax
-- - - - - - - -
esuria.com.bn
0.0%0.1%0.3%0.3%3.7%95.6% 17.45 hours
ims-ms-daemon
33.3%0.0%0.0%0.0%0.0%66.7% 9.38 hours
fortinet.com
0.0%0.0%0.0%0.0%0.0% 100.0% 6.35 hours
ingrammicro-asia.com
0.0%0.0%0.0%0.0%0.0% 100.0% 6.35 hours
pb.com.bn
0.0%0.0% 100.0%0.0%0.0%0.0% 12 secs
Retry counts
Channel1st time 2nd time <5 times >5 times
-- -- -- -- --
# 5
Hi,
I have run the updated script against my mail.log (comm4). I do not have production data for comm5 as I am still evaluating it.
There are about 305 lines of "Found an unsupported record type". Examples of such record are:
a)
U TCP|172.16.3.65|25|125.225.102.102|4409 SMTP No such user 535 5.7.8 Bad username or password (Authentication failed).
b)
U TCP|172.16.3.65|25|172.16.2.102|3653 SMTP Switched to channel tcp_auth user@domain 235 2.7.0 LOGIN authentication successful.
The following is the transit time from the latest script.
Message delays (time from enqueue to dequeue):
Channel<2 sec <10 sec <1 min <5 mins <1 hour >1 hourMax
-- - - - - - - -
ims-ms0.0%0.0%0.0%0.0%0.0% 100.0% 2818.57 hours
process0.0%12.5%12.5%0.0%0.0%75.0% 1094.82 hours
reprocess0.0%0.0%0.0%0.0%0.6%99.3% 2221.15 hours
tcp_local0.0%0.0%0.0%0.0%0.1%99.9% 2477.14 hours
Message transit times
Time from enqueue to dequeue, top 20 hosts by total transit time):
Host<2 sec <10 sec <1 min <5 mins <1 hour >1 hourMax
-- - - - - - - -
local delivery
0.0%0.0%0.0%0.0%0.0% 100.0% 2818.57 hours
esuria.com.bn
0.0%0.0%0.0%0.0%0.3%99.7% 2221.15 hours
sun.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2453.58 hours
mail.esuria.com.bn
0.0%0.0%2.6%0.0%0.0%97.4% 2117.02 hours
rbts.com.bn
0.0%0.0%0.0%0.0%0.0% 100.0% 1172.28 hours
gmail.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2446.80 hours
singnet.com.sg
0.0%0.0%0.0%0.0%0.0% 100.0% 2473.61 hours
pb.com.bn
0.0%0.0%0.0%0.0%0.0% 100.0% 2477.14 hours
microsoft.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2354.20 hours
rba.com.bn
0.0%0.0%0.0%0.0%0.0% 100.0% 2472.90 hours
simpur.net.bn
0.0%0.0%0.0%0.0%0.0% 100.0% 2447.76 hours
yahoo.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2470.18 hours
oracle.com
0.0%0.0%0.0%0.0%0.0% 100.0% 1828.41 hours
cshlawyers.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2454.05 hours
freme.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2310.15 hours
ingrammicro-asia.com
0.0%0.0%0.0%0.0%0.0% 100.0% 1829.23 hours
techdisti.com
0.0%0.0%0.0%0.0%0.0% 100.0% 2279.72 hours
baiduri.com
0.0%0.0%0.0%0.0%0.0% 100.0% 843.18 hours
brunet.bn
0.0%0.0%0.0%0.0%0.0% 100.0% 2454.69 hours
Retry counts
Channel1st time 2nd time <5 times >5 times
-- -- -- -- --
The times taken are still unreasonably high. What could be the problem?
# 6
Hi,
Do you want to send me a sanitised version of your mail log to the email address I sent you the imslog.pl script and I will take a look tomorrow. Chances are I either stuffed up some maths, or the wrong fields are being read in or something like that.
For the "U" line, this is "Logs SMTP authentication successes and failures. Format is the same as other O and C entries. In particular, the same
application and transport information fields appear in same order. The username will be logged in the username field if it is known. Bit 7 (value 128) of the LOG_CONNECTION MTA option controls this."
Most people don't enable this value so it hasn't come up yet --> easily fixed.
Cheers,
Shane.