Nick Tait:
> Hi David.
>
> I think I can guess what your problem is, because I had exactly the same
> symptom with a different bulk email provider...
>
> Basically this sounds like an MTU issue: The SMTP client
> (mailomta12-sa.btinternet.com[213.120.69.18] in your case) is able to
> establish the TCP connection to your server, and the first few SMTP
> requests and responses work fine, because the packets are small. Then
> when it tries to transmit the content of an email (after the DATA
> command), the packets get blocked because they exceed the maximum size
> that will fit through your Internet connection, and this causes the TCP
> connection to stall, and inevitably time out.
Postfix users have seen lost connections caused by broken TCP window
scaling implementations (though I am not sure if that would result in
a lost connection after DATA, having received 0 bytes).
If window scaling is the problem, use tcp_windowsize as described
below.
Wietse
http://www.postfix.org/postconf.5.html#tcp_windowsize
tcp_windowsize (default: 0)
An optional workaround for routers that break TCP window scaling.
Specify a value > 0 and < 65536 to enable this feature. With Postfix
TCP servers (smtpd(8), qmqpd(8)), this feature is implemented by the
Postfix master(8) daemon.
To change this parameter without stopping Postfix, you need to first
terminate all Postfix TCP servers:
# postconf -e master_service_disable=inet
# postfix reload
This immediately terminates all processes that accept network connec-
tions. Next, you enable Postfix TCP servers with the updated tcp_win-
dowsize setting:
# postconf -e tcp_windowsize=65535 master_service_disable=
# postfix reload
If you skip these steps with a running Postfix system, then the
tcp_windowsize change will work only for Postfix TCP clients (smtp(8),
lmtp(8)).
