Can't delivery email due to 451 Timeout waiting for client input

Thanks for your prompt response, jlevie.

The link speed is ok. Also our testing msg is very small size.

I try to use the mail server (8.12.10) to send testing msg, it is ok and the response is fast. But I try to send from internal email to that mail server to outside. The error msg 451 appear.

I try to surf from the internet, I guess it may be the esmtp broken. I try to enable O TLSSrvOptions=V the in sendmail.cf, and also, the access file as
Try_TLS:mail.xxx.com            NO
Try_TLS:xxxx.com                  NO
Srv_Features:mydomain.com      v
Srv_Features:                           V

It seems no any difference.

It always stop after
354 Start mail input; end with <CRLF>.<CRLF>

No any response until timeout. It drives me crazy ....

If you have any idea or hint, please let me know. Thanks you very much.

So you have an one sendmail box running 8.12.10 that will conduct all Internet mail transactions. Mail tests from that box to external mail servers appears to work fine. And your problem occurs when you try to relay mail from an inside system through the Sendmail box.

Why do you have the TLS directives enabled? I assume those are on the Sendmail server that acts as the relay.

From an inside machine can you send mail to an account on the Sendmail box?

What clients are you sending the mail from?

Dear jlevie,

   Our side infrastructure is

O2K - MSX 5.5 <-> Internal sendmail Mailhub <- FW -> External Sendmail Server (8.12.10) <-> Internet

Fm O2K send to "A" domain through the above routing path, then 451 Timeout wait the client input.

Fm External Sendmail send to "A" domain (using /usr/lib/sendmail -v xxx@A.com < test), the email can deliver.

One more phen.,
Show as
354 Start mail input; end with <CRLF>.<CRLF>
 after RCPT. Then the mail will be waiting and defered later.

But, show as
354 Enter mail, end with "." on a line by itself
 after RCPT then the mail can successfully deliver.

It is useful to solve this issue. Many thanks jlevie

"354 Start mail input; end with <CRLF>.<CRLF>" sounds like it is coming from your exchange server. A sendmail server will issue "354 Enter mail, end with "." on a line by itself" when it is ready to accept the message body. And in fact that's what I see in the log output. shown above. The transaction appears to be between sendmail and an exchange server.

I can't tell from the log whether sendmail delivered the body and ended it with the RFC standard ". on a line by itself" or whether it ever send the body. That information would have to come from a sniffer trace of a failed transaction.

If I was to hazard a guess I'd say that it is probably an exchange problem rather than a sendmail issue.

Dear jlevie,

  I will try to use the sniffer to capture the traffic. I let you know what is the status

  One query, in this case, our external sendmail server communicate with other side (using MSX2K - 220 xxx.xxx.xxx.xx Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 read )
  The 354 Start mail input; end with <CRLF>.<CRLF>" should be issue from other side. But our side will be hang or wait until timeout, then the MSX2K prompt 451.

   However, I try to submit email from the external sendmail server directly or using telnet mode, then after RCPT issue 354 Enter mail, end with "." on a line by itself
then email can send successfully.

  Thanks Jlevie.
   

Dear jlevie,

   I find the following article about the lost connection, and it is very close to my case. Do you think it may be the cause of my case ? If yes, I will close this case and give the point to you. Many thank for your help.

Mail fails with timeout or lost connection
Occasionally, mail fails with "timed out while sending end of data -- message may be sent more than once", or with: "lost connection after DATA". Network outages happen, systems crash. There isn't much you can do about it.
However, when you see mail deliveries fail consistently, you may have a different problem: broken path MTU discovery.

A little background is in order. With the SMTP protocol, the HELO, MAIL FROM and RCPT TO commands and responses are relatively short. When you're talking to sendmail, every command and every response is sent as a separate packet, because sendmail cannot implement ESMTP command pipelining.

The message content, however, is sent as a few datagrams, each datagram typically a kbyte large or even bigger, depending on your local network MTU.

When mail fails consistently due to a timeout, I suspect that the sending machine runs a modern UNIX which implements path MTU discovery. That causes the machine to send packets as large as it would send over the LAN, with the IP DONT'T FRAGMENT bit set, preventing intermediate routers from fragmenting the packets that are too big for their networks.

Depending on what network path a message follows, some router on the way responds with an ICMP MUST FRAGMENT message saying the packet is too big. Normally, the sending machine will re-send the data after chopping it up into smaller pieces.

However, things break when some router closer to the sending system is dropping such ICMP feedback messages, in a mistaken attempt to protect systems against certain attacks. In that case, the ICMP feedback message never reaches the sending machine, and the connection times out.

This is the same configuration problem that causes trouble with web servers behind a misconfigured packet filter: small images/files are sent intact, large images/files time out because the server does not see the MUST FRAGMENT ICMP feedback messages.

Workaround: disable path MTU discovery at the sending machine. Mail will get out, but of course everyone else will still suffer. How to disable path MTU discovery? It depends. Solaris has an ndd command; other systems use different means such as sysctl to control kernel parameters on a running system.

Fix: find the router that drops the ICMP MUST FRAGMENT messages, and convince the person responsible for it to fix the configuration.