Scratch my previous suggestion as it was obviously not the correct solution. Read on.
On 5/4/2014 9:01 AM, post...@nisny.com wrote: > On , wie...@porcupine.org wrote: >> post...@nisny.com: >>> There were several attempts from postfix to connect to 6 different mx >>> servers to deliver one email. They all have the same result so I'm only >>> including the dump of the first here: >> >> We see SYN, SYN|ACK, ACK, and a bunch of retransmissions. >> >> SYN: Initial client window 1400 (scale 6), options [mss >> 1460,nop,wscale >> 6,sackOK,TS] >> >> SYN|ACK: Initial server window 33304 (scale 1), options >> [nop,nop,TS,mss >> 1460,nop,wscale 1,nop,nop,sackOK]. >> >> Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until >> the server sends a RESET. The TCP handshake never completes. And >> someone may already have posted the solution. >> >> For the telnet connection we have a successful handhake. >> >> SYN: Initial client window 65535 (scale 6), same TCP options as >> >> SMTP client. SYN|ACK: Same initial server window and TCP options >> as STMP server. >> >> The only difference I see is the initial 1400 client TCP window >> size. >> >> As someone already suggested in one of the first follow-ups: >> >> "Would you mind trying to remove "tcp_windowsize = 1400" from >> you configuration (do not forget to issue a "postfix reload" >> afterwards!)?" >> >> Wietse > > Wietse, > > Thank you for your patience with me. I tried way too long trying to > resolve this on my own. > > I totally forgot that was in main.cf (from months ago trying to resolve > a separate issue and missed it in postconf -n output. (the issue in > question is a networking problem at the provider and the main reason for > the move). > > The funny thing is that directive is on the old server as well, which > had no problems connecting to akamai, Are both the old and new server in the new provider's network at this point. It would be informative to compare SMTP session capture of both systems when "tcp_windowsize = 1400" is configured. I.e. test the old system and compare to the capture you already have for the new system. At this point you know what Postfix setting caused the problem on the new server, but you don't know why it caused a problem, you don't know the root cause. Knowing that root cause may be very useful in the future. > At any rate, removing the directive and a reload, postqueue -f resolved > the issue completely. Cheers, Stan
