Timed out while sending message body
Tomasz K. Jarzynka
they are in the same network). The error message is as follows:
Apr 18 18:02:14 mailhub postfix/smtp[15595]: D71681493B35: conversation with
smtp1.mnisw.gov.pl[195.187.32.7] timed out while sending message body
The message then stays in the queue, subsequent delivery attempts are made but all
fail and eventually the message is returned. It only occurs with this particular
domain, and from what I've learnt they didn't have such trouble reported by anyone
else. This happens when a message has attachments (a couple hundred kilobytes is
enough to trigger the problem), small messages seem to be delivered fine.
I've contacted the administrator of the destination servers and he claims that they
are not using any kind of live message scanning.
What's more, there is another mail server here in the same C class (not administered
by us) and it doesn't have problems with delivering mail to those
servers. The only difference is that it's not behind the same firewall that our mail
server.
Put all together, I suspect there must be some configuration issues on our firewall
or network interface of the mail server. Unfortunately, I haven't been able to
track down the source of the problem and the network parameters of these servers
are pretty generic.
Finally, I ran a tcpdump on our origin mail server, our firewall and the
destinantion mail server (thanks to the help of its administrator) but the output
is inconclusive to me. On our side, It looks like transmission stalls after
a couple hundred bytes + subsequent retransmissions eventually leading to a
timeout. On the destination side, it looks like the connection is ended immediately
after the start of transmission.
Does anyone by any chance have a clue what might be the source of the issue? If so,
could you please be kind enough to have a look at the dumps to see whether they
contain any more useful information?
Maybe there's something more I could do to pinpoint the problem?
The dumps are available on http://tomee.users.genesilico.pl/mail/.
Thank you in advance!
--
Tomasz Krzysztof Jarzynka / tel. +48 22 597 07 45 / mob. +48 601 706 601
Network Information Systems Administrator / tomee(at)genesilico(d-o-t)pl
Laboratory of Bioinformatics and Prot. Engineering | iimcb.genesilico.pl
International Institute of Molecular and Cell Biology | www.iimcb.gov.pl
Wietse Venema
> Finally, I ran a tcpdump on our origin mail server, our firewall
> and the destinantion mail server (thanks to the help of its
> administrator) but the output is inconclusive to me. On our side,
> It looks like transmission stalls after a couple hundred bytes +
> subsequent retransmissions eventually leading to a timeout. On
> the destination side, it looks like the connection is ended
> immediately after the start of transmission.
Google for
1 - IP path MTU discovery.
2 - TCP window scaling.
Wietse
Mark Martinec
This doesn't look like a PMTU discovery problem, more like a NAT screwup.
A duplicate ACK packet #78 in mnisw-fw.dump seems to get translated
into a packet #81 in mnisw-mailhub.dump with a wrong sequence number
and with no NAT translation. This causes your mailer to RST the seemingly
new session, this RST is then seen by the remote side as an original
session reset.
Mark