Messaging Gateway

I have a SMG 9.5.2-3 box that forwards suspected spam/enhanced disposition messages to a separate SMS box altogether. The only function of this box is to have the messages in the spam quarantine interface and notify end users.

For some peculiar reason, the notifications stopped triggering some time back. After rebooting the box, notifications started coming again as per the scheduler. While looking into the brightmail.log.log files could see entries like this. Can some body from the product team please help me out iin identifying where the breakage was?

Just FYI....although the below message gives some information on the downstream host, can assure you that the downstream host was available all this time.

Nov 22 2011 13:51:40 [BrightmailScheduler_Worker-1] ERROR - javax.mail.MessagingException: Can't send command to SMTP host;

  nested exception is:

                java.net.SocketException: Broken pipe

Nov 22 2011 13:51:40 [BrightmailScheduler_Worker-1] ERROR - Cannot notify the user that he or she has new spam messages.

com.brightmail.common.BrightmailException: Can't send command to SMTP host;

  nested exception is:

                java.net.SocketException: Broken pipe ; nested exception is:

                 javax.mail.MessagingException: Can't send command to SMTP host;

  nested exception is:

                java.net.SocketException: Broken pipe

                at com.brightmail.service.mail.impl.MailSend.sendNotificationMessage(MailSend.java:220)

Unfortunately, there is not quite enough information here to really tell what happened. The error indicates that the connection was lost to the downstream server for that particular interaction. I understand that the downstream server was available the whole time, but did you try a telnet test to make sure it was accepting full communication from the SMG appliance?

An example of a telnet test (if you're not familiar) can be seen in the following KB (though it is more specific to testing the appliance itself):

http://www.symantec.com/business/support/index?page=content&id=TECH83693

Typically, this type of issue tends to be related to configurations of the network or downstream mail server. For instance, recent versions of Exchange have a security feature called tarpitting that result in similar situations:

http://www.symantec.com/business/support/index?page=content&id=TECH161742

The tarpitting issue does not quite fit the error you are showing, but it gives a similar example. Also, you would want to check the logs of the downstream server to see if there are any correlating errors listed.

 I had checked the reachability status of the downstream server via a telnet and the connection was open. Moreover, when I rebooted the quarantine server, the issue of notifications getting triggered got solved almost immediately. I could see all the pending notifications arriving at the scheduled time.

Just wanted to understand, can the notification process scheduler could have gone to a hung mode or not?

Typically no. And if the process was hung you would likely see issues beyond just the scheduled notification. The error that you posted indicates that the notification process was working but had problems with the connection to the destination. This could be any of: the downstream mail server (which you believe is not the case), the network itself, the ability of the Messaging Gateway to communicate on the network, or it could be something that we are not able to determine with just that log snippet. Unfortunately, post mortem research on something like this can be difficult, depending on what is in the logs. Out of curiousity, did you try restarting just the Control Center process?

It may also be worth it to mention that the Symantec Messaging Gateway was not designed to be a stand alone quarantine server, so it is possible that the configuration itself may have played a role in the delivery failure. You may want to look at other logs as well to see if there is any indication of network or socket issues.