Re: Google 7720 Error [thread on hold pending useful data]
On May 15, 2011, at 1:14 AM, Frank Bonnet wrote: Le 15/05/2011 02:42, jason hirsh a écrit : On May 14, 2011, at 2:20 PM, Victor Duchovni wrote: On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote: I have also tried running the server with the IPFW turned off and still have the issue with some gmail and mindspring.com users I would like to suggest that further posts in this threat are moot, and should cease, unless and until jason is able to record TCP sessions between Gmail (or another problem systems) and his server, and make at least one such recordings available. Isolate a single session that fails along the lines of: C: TCP SYN (one or more if server response is delayed) S: TCP SYN ACK or TCP RST or silence C: TCP ACK S: SMTP 4XX banner or 5XX or timeout C: SMTP EHLO S: 4XX response or 5XX response or timeout Save a binary packet capture not decoded packets: # tcpdump -s0 -w /some/file tcp port 25 then decode with tcpdump -s0 -r /some/file and find the source host/port of the failed connection, isolate that with: # tcpdump -s0 -r /some/file -w /some/other-file tcp and \ host addr and tcp port port then make the final binary file containing just the failed session available. -- That makes sense I hall attempt to do that Viktor. It seems you are using FreeBSD, could you type the following command then send back the result ? sysctl -a | grep tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 720 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 25 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 50 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 44 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 6 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 3 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.flowtable.tcp_expire: 86400 Is BPF enabled in the kernel machine ? aooarently yes What is the FreeBSD version ( I had troubles with 8.2 ) 8.1 In fact the problem seems to be OS related and NOT a Postfix/ sendmail/exim problem. I will give that a shot thank you I would suggest to post your request into freebsd-us...@freebsd.org mailing list or look at http://lists.freebsd.org/mailman/listinfo to find a more fine grained list
Re: Google 7720 Error [thread on hold pending useful data]
On May 15, 2011, at 1:14 AM, Frank Bonnet wrote: Le 15/05/2011 02:42, jason hirsh a écrit : On May 14, 2011, at 2:20 PM, Victor Duchovni wrote: On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote: I have also tried running the server with the IPFW turned off and still have the issue with some gmail and mindspring.com users I would like to suggest that further posts in this threat are moot, and should cease, unless and until jason is able to record TCP sessions between Gmail (or another problem systems) and his server, and make at least one such recordings available. Isolate a single session that fails along the lines of: C: TCP SYN (one or more if server response is delayed) S: TCP SYN ACK or TCP RST or silence C: TCP ACK S: SMTP 4XX banner or 5XX or timeout C: SMTP EHLO S: 4XX response or 5XX response or timeout Save a binary packet capture not decoded packets: # tcpdump -s0 -w /some/file tcp port 25 then decode with tcpdump -s0 -r /some/file and find the source host/port of the failed connection, isolate that with: # tcpdump -s0 -r /some/file -w /some/other-file tcp and \ host addr and tcp port port then make the final binary file containing just the failed session available. this is the record of the exchange.. it does not appear to be what you expected though 08:40:31.036997 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0 08:40:34.037857 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972298960 ecr 0,nop,wscale 6], length 0 08:40:40.036791 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972304960 ecr 0,nop,wscale 6], length 0 08:40:50.037758 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972314960 ecr 0,nop,wscale 6], length 0 08:41:00.037805 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972324960 ecr 0,nop,wscale 6], length 0 08:41:10.037831 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972334960 ecr 0,nop,wscale 6], length 0 -- That makes sense I hall attempt to do that Viktor. It seems you are using FreeBSD, could you type the following command then send back the result ? sysctl -a | grep tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 720 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 25 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 50 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 44 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 6 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200
Re: Google 7720 Error [thread on hold pending useful data]
On May 15, 2011, at 8:54 AM, Jeroen Geilman wrote: On 05/15/2011 02:50 PM, jason hirsh wrote: this is the record of the exchange.. it does not appear to be what you expected though 08:40:31.036997 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0 08:40:34.037857 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972298960 ecr 0,nop,wscale 6], length 0 08:40:40.036791 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972304960 ecr 0,nop,wscale 6], length 0 08:40:50.037758 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972314960 ecr 0,nop,wscale 6], length 0 08:41:00.037805 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972324960 ecr 0,nop,wscale 6], length 0 08:41:10.037831 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972334960 ecr 0,nop,wscale 6], length 0 Your server is not responding to TCP SYN. OK but why just that one server here is an exchnage with another server thatr appears normal.. 08:39:54.189545 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 34, win 33304, options [nop,nop,TS val 317610222 ecr 3017712232], length 133 08:39:54.189611 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [P.], ack 191, win 8326, options [nop,nop,TS val 3017712351 ecr 317610222], length 111 08:39:54.199460 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [.], ack 145, win 33304, options [nop,nop,TS val 317610223 ecr 3017712351], length 0 08:39:54.201472 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 145, win 33304, options [nop,nop,TS val 317610223 ecr 3017712351], length 8 08:39:54.229704 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 145, win 33304, options [nop,nop,TS val 317610226 ecr 3017712351], length 8 08:39:54.229717 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [.], ack 207, win 8325, options [nop,nop,TS val 3017712391 ecr 317610223], length 0 08:39:54.230072 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 145, win 33304, options [nop,nop,TS val 317610226 ecr 3017712351], length 8 08:39:54.230143 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [.], ack 215, win 8326, options [nop,nop,TS val 3017712391 ecr 317610226], length 1448 08:39:54.230149 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [P.], ack 215, win 8326, options [nop,nop,TS val 3017712391 ecr 317610226], length 338 08:39:54.241318 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [.], ack 1931, win 33304, options [nop,nop,TS val 317610227 ecr 3017712391], length 0 08:39:54.244078 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 1931, win 33304, options [nop,nop,TS val 317610227 ecr 3017712391], length 39 08:39:54.244161 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [P.], ack 1931, win 33304, options [nop,nop,TS val 317610227 ecr 3017712391], length 13 08:39:54.244169 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [.], ack 267, win 8324, options [nop,nop,TS val 3017712405 ecr 317610227], length 0 08:39:54.244214 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [F.], seq 1931, ack 267, win 8326, options [nop,nop,TS val 3017712405 ecr 317610227], length 0 08:39:54.253854 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [.], ack 1932, win 33304, options [nop,nop,TS val 317610228 ecr 3017712405], length 0 08:39:54.253968 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow- bv.com.35659: Flags [F.], seq 267, ack 1932, win 33304, options [nop,nop,TS val 317610228 ecr 3017712405], length 0 08:39:54.253983 IP tuna.theoceanwindow-bv.com.35659 scc- mailrelay.att.net.smtp: Flags [.], ack 268, win 8325, options [nop,nop,TS val 3017712415 ecr 317610228], length 0 -- J.
Re: Google 7720 Error [thread on hold pending useful data]
On 05/15/2011 03:18 PM, jason hirsh wrote: On May 15, 2011, at 8:54 AM, Jeroen Geilman wrote: On 05/15/2011 02:50 PM, jason hirsh wrote: this is the record of the exchange.. it does not appear to be what you expected though 08:40:31.036997 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0 08:40:34.037857 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972298960 ecr 0,nop,wscale 6], length 0 08:40:40.036791 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972304960 ecr 0,nop,wscale 6], length 0 08:40:50.037758 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972314960 ecr 0,nop,wscale 6], length 0 08:41:00.037805 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972324960 ecr 0,nop,wscale 6], length 0 08:41:10.037831 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972334960 ecr 0,nop,wscale 6], length 0 Your server is not responding to TCP SYN. OK but why just that one server here is an exchnage with another server thatr appears normal.. 08:39:54.189545 IP scc-mailrelay.att.net.smtp tuna.theoceanwindow-bv.com.35659: Flags [P.], ack 34, win 33304, options [nop,nop,TS val 317610222 ecr 3017712232], length 133 No, it looks nothing like the previous: 08:40:31.036997 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0 You need to show the complete TCP setup in order to compare them. -- J.
Re: Google 7720 Error [thread on hold pending useful data]
On Sun, May 15, 2011 12:54 pm, Jeroen Geilman wrote: On 05/15/2011 02:50 PM, jason hirsh wrote: this is the record of the exchange.. it does not appear to be what you expected though 08:40:31.036997 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972295960 ecr 0,nop,wscale 6], length 0 08:40:34.037857 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972298960 ecr 0,nop,wscale 6], length 0 08:40:40.036791 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972304960 ecr 0,nop,wscale 6], length 0 08:40:50.037758 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972314960 ecr 0,nop,wscale 6], length 0 08:41:00.037805 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972324960 ecr 0,nop,wscale 6], length 0 08:41:10.037831 IP mail-iy0-f182.google.com.51101 tuna.theoceanwindow-bv.com.smtp: Flags [S], seq 850119283, win 5720, options [mss 1430,sackOK,TS val 2972334960 ecr 0,nop,wscale 6], length 0 Your server is not responding to TCP SYN. Or perhaps the kernel never sees them. If the OP ran tcpdump on tuna.theoceanwindow-bv.com, having ipfw log discarded or rejected packets would give additional insight.
Re: Google 7720 Error [thread on hold pending useful data]
On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote: I have also tried running the server with the IPFW turned off and still have the issue with some gmail and mindspring.com users I would like to suggest that further posts in this threat are moot, and should cease, unless and until jason is able to record TCP sessions between Gmail (or another problem systems) and his server, and make at least one such recordings available. Isolate a single session that fails along the lines of: C: TCP SYN (one or more if server response is delayed) S: TCP SYN ACK or TCP RST or silence C: TCP ACK S: SMTP 4XX banner or 5XX or timeout C: SMTP EHLO S: 4XX response or 5XX response or timeout Save a binary packet capture not decoded packets: # tcpdump -s0 -w /some/file tcp port 25 then decode with tcpdump -s0 -r /some/file and find the source host/port of the failed connection, isolate that with: # tcpdump -s0 -r /some/file -w /some/other-file tcp and \ host addr and tcp port port then make the final binary file containing just the failed session available. -- Viktor.
Re: Google 7720 Error [thread on hold pending useful data]
On May 14, 2011, at 2:20 PM, Victor Duchovni wrote: On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote: I have also tried running the server with the IPFW turned off and still have the issue with some gmail and mindspring.com users I would like to suggest that further posts in this threat are moot, and should cease, unless and until jason is able to record TCP sessions between Gmail (or another problem systems) and his server, and make at least one such recordings available. Isolate a single session that fails along the lines of: C: TCP SYN (one or more if server response is delayed) S: TCP SYN ACK or TCP RST or silence C: TCP ACK S: SMTP 4XX banner or 5XX or timeout C: SMTP EHLO S: 4XX response or 5XX response or timeout Save a binary packet capture not decoded packets: # tcpdump -s0 -w /some/file tcp port 25 then decode with tcpdump -s0 -r /some/file and find the source host/port of the failed connection, isolate that with: # tcpdump -s0 -r /some/file -w /some/other-file tcp and \ host addr and tcp port port then make the final binary file containing just the failed session available. -- That makes sense I hall attempt to do that Viktor.
Re: Google 7720 Error [thread on hold pending useful data]
Le 15/05/2011 02:42, jason hirsh a écrit : On May 14, 2011, at 2:20 PM, Victor Duchovni wrote: On Sat, May 14, 2011 at 01:56:00PM -0400, jason hirsh wrote: I have also tried running the server with the IPFW turned off and still have the issue with some gmail and mindspring.com users I would like to suggest that further posts in this threat are moot, and should cease, unless and until jason is able to record TCP sessions between Gmail (or another problem systems) and his server, and make at least one such recordings available. Isolate a single session that fails along the lines of: C: TCP SYN (one or more if server response is delayed) S: TCP SYN ACK or TCP RST or silence C: TCP ACK S: SMTP 4XX banner or 5XX or timeout C: SMTP EHLO S: 4XX response or 5XX response or timeout Save a binary packet capture not decoded packets: # tcpdump -s0 -w /some/file tcp port 25 then decode with tcpdump -s0 -r /some/file and find the source host/port of the failed connection, isolate that with: # tcpdump -s0 -r /some/file -w /some/other-file tcp and \ host addr and tcp port port then make the final binary file containing just the failed session available. -- That makes sense I hall attempt to do that Viktor. It seems you are using FreeBSD, could you type the following command then send back the result ? sysctl -a | grep tcp Is BPF enabled in the kernel machine ? What is the FreeBSD version ( I had troubles with 8.2 ) In fact the problem seems to be OS related and NOT a Postfix/sendmail/exim problem. I would suggest to post your request into freebsd-us...@freebsd.org mailing list or look at http://lists.freebsd.org/mailman/listinfo to find a more fine grained list
