Autor: W B Hacker Datum: To: exim-users Betreff: Re: [exim] SMTP Timeout
Marc Sherman wrote:
> Frederik Meerwaldt wrote:
>
>>Dear List members,
>>
>>I have a problem with my Exim configuration.
>>I currently have my home mail-router running Exim 4.50 and my remote
>>server running Exim 4.62.
>>My home mail-router receives mail from my home-network, forwards it
>>(TLS encrypted, Auth-Plaintext) to my remote server (because my home-
>>box has a dial-up IP which many providers reject), and my remote
>>server delivers the mail then.
>>
Even if you have a hundred devices on your 'home network' it
would seem simpler to set thir MUA's to use the remote server
directly. If even one of those devices is a laptop, it can then
travel the world with no MUA settings changes.
That will not necessarily resolve this problem, but can make
life simpler.
Updating your 'home' mx to current Exim is also a good idea, as
ISTR several worthwhile bug fixes and enhancements between 4.5X
and 4.6X.
>>My connection is not a really slow modem line, but a 1 MBit ADSL
>>line, which should be enough for that purpose?!
>
>
> Sounds like it might be a MTU problem, to me.
>
> - Marc
>
>
MTU-size is a known 'challenge' with the way many ADSL providers
configure their service. Exim can be re-compiled with a default
MTU size that will 'fit' those cases where discovery/negotiation
is blocked and bits have been robbed by the ISP and/or
discovery/handshake is blocked.
Others things to look for include:
- Conectivity ISP, (common) hosting ISP, (less so) or your own
firewall or frewall ruleset blocking/dropping packets needed for
dscovery/negotiation of mtu handling.
- ISP using rapid dynamic reassignment of DHCP IP in an attempt
to block VoIP, etc. (PCCW Hong Kong and other PPoE providers do
this).
- A NIC at either end that has flawed silicon or driver code
(SiS on FreeBSD 4.X was one such).
'tcpdump' should show you what is happening. 'man tcpdump'
Look for a normal initial transfer rate, followed by a drop-off
in incoming packets, eventual timeout.
Presuming this does not affect scp/sftp transfer of large files
over the same connection, try also temporarily dropping Exim out
of TLS into unencrypted for that route, and see if the problem
persists.
'tcpdump' is your friend, and Exim 'logselector = +all' helps also.