Author: Cyborg Date: To: exim-users Subject: Re: [exim] Exim problem with non-TLS supporting senders
Am 05.10.2012 12:42, schrieb Emmanuel Noobadmin: > I've some users that cannot receive emails from a particular domain.
> On checking the logs, I see massive ton of incomplete transaction like
> this
>
> incomplete transaction (connection lost) from <xxx@xxxx> for yyy@yyy
> unexpected disconnection while reading SMTP command from ()
>
> Running a mxtoolbox.com check on the other server seems to point to
> the fact the sender's server does not support TLS.
>
> I'm reluctant to disable TLS on exim just because of one sender so
> wondering what is the best way to handle such senders?
> i know those .. i had those messages for connections from windows to linux.
I don't think TLS will help you or cause it in any way. Disabling will
help you to understand it.
This was the situation i had :
the windows client starts the connection normaly..
SMTP headers got exchanged
SMTP Data got delivered from the windows system
Windows should now send QUIT , but it never happend on our side.
Windows did indeed send it on his side , but it never reached the linux
server, which assumed after the tcp timeout, that the connection got
dropped on the other side.
It was caused by a very odd combination of linux and windows
kernel/tcp/ip stacks,
After a while, that customer involved got a windows update and it
magically worked again, which it didn't do for months.
learned solutions :
update your kernel to something different
update the externel machine to something different.
Details:
it got caused by a specific tcp window size, which both tcp/ip stacks
refused to work with correctly.
The linux kernel devs refused to rework it in the kernel and the
reactions from M$ was to refuse to react to it in any form ( of course ) :)
But, your problem could also be located on the sending server alone. If
you want to find out, you have to work with the admin there and make use
of tcpdump a lot.
