Wietse Venema <[EMAIL PROTECTED]> wrote: > > Oct 10 10:09:56 aegis postfix/smtpd[53022]: timeout after DATA (3240605 > > bytes) from relay.airtiger.com[63.170.171.120] > > Oct 10 11:09:36 aegis postfix/smtpd[53463]: timeout after DATA (2998025 > > bytes) from relay.airtiger.com[63.170.171.120] > > If the last two are really hourly retransmissions, then their > inbound bitrate is very low (ball-park 100kbit/second). > > > HOST: aegis.hamla.org Loss% Snt Last Avg Best Wrst StDev > > 1. bfw02.m5hosting.com 0.0% 10 2.4 1.8 0.5 3.7 1.1 > > 2. br02.sdtc.m5hosting.net 0.0% 10 2.5 55.4 2.3 528.5 166.2 > > 3. ais-ar01.sdtc.m5hosting.net 0.0% 10 0.8 16.6 0.5 118.7 36.9 > > 4. owb.br03.g5-1.americanis.net 0.0% 10 4.7 4.7 4.6 4.9 0.1 > > 5. 207.43.189.209 0.0% 10 69.0 35.3 4.7 101.0 40.4 > > 6. sl-crs2-ana-0-13-3-0.sprintl 0.0% 10 5.7 5.5 5.3 5.8 0.1 > > 7. sl-crs2-ana-0-8-0-0.sprintli 0.0% 10 5.3 5.4 5.3 5.5 0.1 > > 8. sl-gw9-ana-4-0-0.sprintlink. 0.0% 10 218.1 26.8 5.3 218.1 67.2 > > 9. sl-airti-5-0.sprintlink.net 0.0% 10 13.4 13.5 12.9 14.8 0.5 > > 10. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > According my own mtr results, there's a 9ms increase in latency at > sl-airti-5-0.sprintlink.net, which suggests they have a low-bandwidth > network connection. > > That is not necessarily bad - my primary connection is slow, too. > But I have experienced trouble sending large email files over slow > connections when equipment isn't working error-free and TCP just > gives up. > > Running tcpdump will show if there are lots of retransmissions, > which I expect there to be. Maybe you can tune your end to try > longer.
Thank you and Viktor for your response. The sending MTA continues to retry on an hourly basis. I ran tcpdump as per the DEBUG_README and pasted one session capture (the output of tshark -n -r tcpdump_file) at the URL below. Prior to tshark, I tried viewing the tcpdump file with the following: tcpdump -nA -r tcpdump_file. However, the output of that commmand reveals the email as it was written, headers, etc. I wasn't sure that was necessary to debug the issue. But if it is, I'm happy to post that as well. I understand it is generally better to paste relevant excerpts in the body, but this particular capture is quite large! [TCP Previous segment lost] is followed by several duplicate ACKs, and eventually a 421 timeout error. http://pastebin.com/m7fb47518 -- Sahil Tandon <[EMAIL PROTECTED]>
