Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Jerry Feldman wrote: > I've seen this a number of times. Kevin had one suggestion, but it simply > could be that the helmsbriscoe server is currently overloaded, or that the > file you are sending is very large. In many cases it takes care of itself > over time. I tried running tcpdump to watch what happens: sudo tcpdump -vv port 25 I then tried telnet to port 25 on helmsbriscoe, and saved the output. I then ran tcpdump a second time, and ran sudo sendmail -v -qRhelmsbriscoe which tried to deliver four messages in the queue. It appears that sendmail is never getting a response from helmsbriscoe at all, so it's failing before it even knows what the message size is going to be. And yet telnet seems to work fine. The only difference I see is that sendmail's outbound packet shows "tos 0x0", whereas telent's outgoing packet shows "tos 0x10" and the reply packet from helmsbriscoe shows "tos 0x0". I have no idea what that means, or if it's significant; I don't see a match for it in the tcpdump manpage. How can I watch what sendmail is doing when I process the queue? I'd like to watch the complete protocol as it happens so I can be certain what it's doing, but I haven't had any luck getting either sendmail or tcpdump to show me that. In the telnet session, I issued a HELO command followed by a QUIT command. tcpdump showed 4 matches: two sent to helmsbriscoe, and two coming back from helmsbriscoe: 14:15:01.180114 IP (tos 0x10, ttl 64, id 5751, offset 0, flags [DF], proto 6, length: 60) brodie.us.zuken.com.57690 > smtp.helmsbriscoe.com.smtp: S [tcp sum ok] 2167306626:2167306626(0) win 5840 <mss 1460,sackOK,timestamp 342192117 0,nop,wscale 2> 14:15:01.267297 IP (tos 0x0, ttl 104, id 59165, offset 0, flags [none], proto 6, length: 64) smtp.helmsbriscoe.com.smtp > brodie.us.zuken.com.57690: S [tcp sum ok] 1141564426:1141564426(0) ack 2167306627 win 16384 <mss 1380,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> 14:15:01.267385 IP (tos 0x10, ttl 64, id 5753, offset 0, flags [DF], proto 6, length: 52) brodie.us.zuken.com.57690 > smtp.helmsbriscoe.com.smtp: . [tcp sum ok] 1:1(0) ack 1 win 1460 <nop,nop,timestamp 342192204 0> 14:15:01.355630 IP (tos 0x0, ttl 104, id 41424, offset 0, flags [DF], proto 6, length: 111) smtp.helmsbriscoe.com.smtp > brodie.us.zuken.com.57690: P 1:60(59) ack 1 win 65535 <nop,nop,timestamp 651755 342192117> When I ran the sendmail queue, the four messages each showed just a single match, sending to helmsbriscoe and never receiving a response: 14:05:44.790198 IP (tos 0x0, ttl 64, id 58975, offset 0, flags [DF], proto 6, length: 60) brodie.us.zuken.com.57532 > hbmail01.helmsbriscoe.com.smtp: S [tcp sum ok] 1572213780:1572213780(0) win 5840 <mss 1460,sackOK,timestamp 341635659 0,nop,wscale 2> -- John Abreau / Executive Director, Boston Linux & Unix ICQ 28611923 / AIM abreauj / JABBER jabr at jabber.org / YAHOO abreauj Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -------------- next part -------------- A non-text attachment was scrubbed... Name: jabr.vcf Type: text/x-vcard Size: 294 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20060613/4dfc1062/attachment.vcf>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |