Exchange Server 2003 and error 4.4.7

check this:

http://support.microsoft.com/kb/303734
and here "Configure Retry Tries and Intervals"

check this:
Delivery status notifications in Exchange Server and in Small Business Server
http://support.microsoft.com/kb/284204

here you can check for 4.4.7

The latest interval on the delivery tab of the smtp virtual server was 2 days - how were messages boluncing back a week later?

Changing the time out is not really something I would advise. If you cut it down to something like an hour then you do not have any flexibility in the event of a problem with you, your ISP or the recipients ISP or SMTP server.

If you got the messages after a restart of the service then you might have seen the greylisting bug, particularly if the queues were clear.

You can deal with greylisting bug by a small registry change.
Copy and paste this to notepad and then save it as a .reg file and merge it.

---Cut here---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Queuing]
"GlitchRetrySeconds"=dword:00000078

---Cut here---

The other cause I have seen is antivirus software hanging on to the message.
In both cases the queues would appear to be clear.

Simon.

Thanks for the advice.  The queues have between 100-300 domains listed, so they are definitely not clear.  Is it normal to have that many?  I'll try the registry edit and see if the messages still get stuck for that long.  

If the messages are not clear then your server is probably being abused.
I would suggest a look at my spam cleanup article: http://www.amset.info/exchange/spam-cleanup.asp

Simon.

Thanks again.  I'll look it over and see what's up.

I use the postini filtering service, and have setup my firewall to only accept incoming messages from a specifc range of IP addresses (the postini service providers), so I don't think abuse is likely.

Just to be on the safe side, and make sure our filters are doing their job, I've done all of the checks listed, and so far we're clean.  I'll have to monitor the smtp events in the Event Logs for a while , and check our queues for NDR attack patterns to make sure we're totally ok.  I'll report back in a few days.  

I appreciate the suggestions thus far.

No, I don't send through Postini.  How do I call back to the sending server to see if the sender is valid?  Our Postini setup does recipient filtering.

You aren't doing the call back, the recipient server is. It sees the address of your server and makes a connection back.

Simon.

Then what do you mean by "If not, then you may want to consider doing that as a common antispam technique is to call back to the sending server to see if the sender is valid"?

If you don't send your email through Postini, then you should look at doing that.
By blocking access to any other SMTP Servers to your server any servers that are looking to verify your server will be unable.

Simon.

I continue to get messages like this from users:

*****************************************************************
Hey admin, my friend tells me that the message (below) I sent on June 27 arrived yesterday, July 5. Strange...

 -----Original Message-----
From:       user  
Sent:      Wednesday, June 27, 2007 1:47 PM
To:      user's friend
Cc:      another user
Subject:      last-minute BBQ invite

blah blah blah

----------
organizational user closing

***************************************************************

Without the full headers of the received message diagnostics is impossible.

Simon.

I don't think I can get headers on that message.  Is there another way?  How do I collect stats on my outgoing queue?  Would outgoing queue stats matter?  

All that your server will tell you is when the message left you. Nothing more.
That is about as useful as knowing when you posted a letter. It doesn't tell you anything more about the path of the email or where the delay could have occurred.

Simon.

So, the only way is to get the headers of the message after it arrives at the destination?

Headers tell you the path of the email. You cannot see the path before the message has been delivered, as you have no way of knowing what path it has taken. You can see partial headers of a message as it leaves your server, but that will not tell you anything other than your server handled the message.

Simon.

By the way, is there a way I can capture and store when messages leave my exchange server?

The journaling feature will capture all email that passes through the server, internal and external. If you want external only then you will need to use a third party tool.

Simon.

Thank you.  How do I set up journaling?

http://support.microsoft.com/default.aspx?kbid=261173

Use a special account, it will fill very quickly.

Simon.

Thank you.

Thanks for all of the help on this thread.  I have decided to get a thrid party tool to monitor outgoing and incoming mail.  I think my users will be satisfied with knowing that the issue is not at our organization, and with information on when their message actually leave here.

This question can be closed.