Messaging Gateway

This is a strange behavior. If the emails are sent to an address without the .com part the NDR keeps coming back to the original sender for more than 5 days.
I have 2 users so far with this problem, where the NDR has been trying to send for more than 5 days. The example below shows that it has been trying for 
46 days already. I can't seem to find the message stuck in any queues and both the Scanner and Scanner/Control center are set up for 5 days.
We are using the 9.0 version of the OS. Any help would be greatly appreciated. How can I solve this?


From Mail Delivery System [Mailer-Daemon@................]


####################################################################
# THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################
 
Your message could not be delivered for 46 days, 12 hours, 0 minutes.
It will be retried until it is 5 days, 0 hours, 0 minutes old.
 
For further assistance, please send mail to <postmaster>
 
If you do so, please include this problem report. You can delete your own text from the attached returned message.
 
<kwertzberger@extendedstay>: Unknown reason
 

I sent a test e-mail to bob@Bob@extendedstay
#< #5.4.4 smtp; 554 5.4.4 [internal] Domain Lookup Failed> #SMTP#
and get this back from my Brightmail server that talks to the internet:

     Bob@extendedstay
     #< #5.4.4 smtp; 554 5.4.4 [internal] Domain Lookup Failed> #SMTP#

There are no items in the servers delivery queue.

When did you upgrade to 9.0.  Could this be a broken item from your 8.03 to 9.01 upgrade?
From your edge box, what does an MX lookup for extendedstay return.

You are seeing a known issue:

Title: 'Some messages that get stuck in the delivery queue of Symantec Brightmail Gateway (SBG) do not report any reason for delivery failure'
Document ID: 2010060313530054
> Web URL: http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2010060313530054?Open&seg=ent

This is something we're aware of and working on fixing in a future release.

JDavis, the workaround - Please make sure that DNS lookups can be performed successfully on the appliance itself for the recipient domain

Does this suggest that vruggiero may have a DNS issue that is agravating this?
when I do an MX lookup I get: can't find extendedstay: Non-existent domain.  The SBG util menu refuses the look up (not a FQDN)

The upgrade was done about a month ago. I am not sure if this was something from the older version but it seems like only emails sent to addresses without the .com or .edu or  .net or .whatever are causing the appliance to keep trying and keep sending these ndr to users. It is version 9.0.0

Here is another one. 35 days and different domain.

The error is also strange: Unknown reason

####################################################################
> # THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
> ####################################################################
>
> Your message could not be delivered for 35 days, 4 hours, 0 minutes.
> It will be retried until it is 5 days, 0 hours, 0 minutes old.
>
> For further assistance, please send mail to <postmaster>
>
> If you do so, please include this problem report. You can delete your
> own text from the attached returned message.
>
> <norfolkcaterimg@thompsonhospitality>: Unknown reason

if I do nslookup -querytype=mx extendedstay  I get:

First - see JDavis' note.

My SBG 9.0.1 box returns
nslookup -querytype=mx extendedstay
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find extendedstay: NXDOMAIN

In your example,  where is says responsible mail addr = netsupport.domain.com
is domain.com your domain?  

If so, then it looks like your local DNS service is adding .domain.com to non-FQDN.  Do you have DNS Suffix Search List enabled somewhere along the line?

No I added that there to mask the real domain. The domain name was the correct one.

How do I stop those NDR from coming back all the time? Do I need to restart the mta? I can't find them in the queue. Is there another queue I can search?

Per the technote:
If the message has stayed longer than the configured time-out in the queue, please restart the mta so that it can enforce the configured time-out on the message and remove it from the queue.

RE: In your example,  where is says responsible mail addr = netsupport.domain.com

So it said mail addr = netsupport.extendedstay.com   ????  it shouldn't, since you didn't supply the .com part.

No. It was  mycompanyname.com

So, when you did

f I do nslookup -querytype=mx extendedstay  I get:  default TTL = 900 (15 mins)

If that is true, then your DNS is doing dns suffix searches.



Did the MTA restart clear the problem?

I just restarted the MTA this morning and we'll see how it goes. I did an nslookup -querytype=mx extendedstay from the mail appliabce and I received:

Yup! the restart of the MTA service on the appliance in question solved the problem with the repeated NDRs. However, how do I prevent this from happening in the future. We have version 9.0.0, is this fixed in 9.0.1?

Per the document I posted, this is a known issue that will be resolved in a future release.

OK!  Thank you for all of your support! I will wait and keep looking for a new release. Any idea for a scheduled update?