PPPoE - Email bug in SonicWall TZ 170

[Corey_ironport]

About six months ago, we received word that one of our business partners was not receiving email from us. The business partner was running a MS Small Business Server 2003 behind a SonicWall TZ 170 firewall connecting to their ISP through PPPoE. I set up a domain debug log on the IronPorts and sent a message. At the end of the body of the message, the IronPort sent a period on a line by itself but never received a response from the recipient server. I contacted the support person for the business, and he was a contractor who had other similar setups around the area. Through process of elimination, we figured out that the problem was the SonicWall TZ 170. In the mean time, I was contacted by another contractor who had at least 50 confirmed cases of companies not able to receive mail from certain domains. It seemed that the IronPort exacerbated the problem as I was never able to get a message past a TZ 170, but other MTAs experienced sporadic success or failure. By the first of the year, SonicWall had agreed that there was a problem with their firmware and was working on it. In February, they released firmware version 3004s for the TZ 170 and it appears to have fixed the PPPoE/Email problem. However, there are already reports from one of the contractors that DHCP is now flakey.

I feel that the problem is especially nasty because the sender never receives an NDR. When the SonicWall drops that packet, it doesn't close the connection with the IronPort. When the contractors upgraded the firmware or replaced the TZ 170s, they started getting mail that they hadn't even realized they weren't getting. The reason that I am sending this message is because SonicWall failed to add the PPPoE/Email bug fix to the release notes, and because I know that there are others out there that are experiencing this. I don't want anyone else to have to spend several months tracking this down.

[shannon.hagan]

Have you reported this to ironport as a bug? If you never receive the 250 response for the period at the end, then the ironport should be delivering an ndr after the specified timeout.

[Corey_ironport]

Not officially. I had an open ticket with them, trying to figure the problem out in the beginning, but we never addressed the fact that if the message was never successfully delivered that the sender should receive a timeout NDR.

[ironporter_ironport]

The C-series are set by default to assume that the message was delivered if the last byte was sent to the other side. It's called "possible delivery" and is enabled by default but can be changed in "deliveryconfig"

I hardly ever recommend changing the default, however, because turning it off can lead to repeated attempts to deliver a message when the recipient doesn't respond properly.

[Corey_ironport]

If the IronPort never gets the "250: Message Accepted/Queued for Delivery" response, they shouldn't assume that the message was delivered. If a message is undelivered after 4 hours, a notice should be sent to the sender, letting them know that the IronPort is unable to send the message, and will keep retrying for 3 days (or whatever timeout is configured in the system). At the end of the 3 (or whatever) days, if the message is still undelivered, the IronPort should send a final NDR to the sender.

That is how it works in the Sendmail world, and I think that it makes a lot more sense than the current IronPort behavior. The current behavior certainly made this problem much worse.

[ironporter_ironport]

If you set the possible delivery setting to "No", the system will wait for that 250. Unfortunately, with some recipient systems this leads to cases where the appliances make multiple deliveries of a single message because the other side just drops the connection without issuing the 250.

If you edit the system's retry parameters using the "bounceconfig" command, you can set the system to give a notification on temporary failures after 4 hours. The system will ask "If a message is undeliverable after some interval, do you want to send a delay warning message to the sender?", and if yes, what interval to send on.

The default interval is 4 hours but the default behavior is NOT to send these warning messages.

Of course it makes sense to only use such a policy for outgoing mail, and that can be set by creating a custom bounce policy for outgoing only.