1

Our SBS 2008 server with Exchange 2007 started rejecting some (most) emails starting about 3 or 4 days ago. The return failure message looks something like this:

The error that the other server returned was: 451 451 4.7.0 Timeout waiting for client input (state 18)

I've rebooted our Sonicwall TZ-210 router and that doesn't make any difference. I think this problem has something to do with MTU (packet size) but I don't understand why the problem just started now. We haven't made any changes to our network infrastructure for weeks.

If I ping our SonicWall (DSL connection, bridge mode) forcing unfragmented packets, I start getting packet dropouts at packet size 1320 or so. Maybe this is completely normal, I'm not sure.

I haven't tried rebooting the DSL modem yet because I'm not on site. That's one of the next things I'll try.

Improve this question
2
  • Help me understand this: When you send email from your Exchange 2007 organization to another email domain, the remote mail server sends back an NDR with the 4.7.0 Timeout waiting for client input (state 18). Is that correctly understood?
    – Mathias R. Jessen
    Dec 28, 2011 at 21:14
  • Other people on other networks that try to send an email to our server/domain get a return failure from their own email sending service (in my case gmail) and it returns the message I posted above. I'm not sure if our server generates that error message or if it's generated by the remote client's sending server.
    – HK1
    Dec 29, 2011 at 2:16

2 Answers 2

Reset to default
1

After reading up more online I did some ping tests using the -f switch and found that this particular DSL connection started dropping packets that were in excess of 1300 bytes. Microsoft refers to this as a "black hole router". Basically, something is wrong with that port.

I implemented a work around for this problem by going into the PPoE connection settings inside the SonicWall TZ-210 and changing the MTU to be somewhere in the 1250 range (I don't remember the exact number). Incoming emails started to flow again immediately as well as any other traffic that uses that particular connection. I'll have to contact SonicWall to see if we can have this problem covered under warranty.

Update1
As it turns out, this was apparently a DSL modem problem, not a SonicWall problem. Changing the MTU setting in the PPoE settings on the router did prove to be a sufficient work-around until the modem gets replaced.

Update2
A new DSL modem did not resolve this issue. Still not sure which device or software is causing this problem.

Update3
I guess I failed to post back here as to what was really wrong. The phone company found some bad hardware in one of their boxes or offices and replaced it. If you're troubleshooting this issue the tricky part is to determine if it's you're own hardware or something outside your LAN.

Improve this answer
0

If it is a routing issue (that's pretty likely, given the error message), try setting the MTU max size on the public interface of your SBS. You can set the package size limit for each individual tcpip interface in the registry.

Check out this guide from Microsoft, the last suggestion "Method 3" walks you through setting MTU max size: http://support.microsoft.com/kb/314825

Improve this answer
2
  • You were real close but it's not really a "routing" issue and neither is the problem located on our server.
    – HK1
    Dec 29, 2011 at 2:13
  • I never said it was located on the server, I simply offered a suggestion that would circumvent the black hole router issue, through a little server configuration ;-)
    – Mathias R. Jessen
    Dec 29, 2011 at 2:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .