SMTP mail to non-existent domain cause delay for another normal emails.
Hello,
I'm using 1 POSTFIX as MTA and 1 Exchange2003SP1 as backend.
In normal situation, everything is okay and the delivery speed of smtp mail to outside is quite fast.(less than a min.)
However if someone(outlook user in inside) send the message to non-existent domain name with typo like "domain.con" (should be ".com")
of cource this message will be stayed on the Exchange smtp queue and reply back with NDR to the sender, but during this period(stay in the queue),
other email also start to stay in the queue. Normal email process delays few mins because of the wrong email.
I've tested this case in the two quite different environment and got a same result.
If you are Exchange admins, please let me know if you can duplicate the issue.
I'd like to resolve this issue. Only one worng email shouldn't be affected to others, I believe.
Thanks.
I'm using 1 POSTFIX as MTA and 1 Exchange2003SP1 as backend.
In normal situation, everything is okay and the delivery speed of smtp mail to outside is quite fast.(less than a min.)
However if someone(outlook user in inside) send the message to non-existent domain name with typo like "domain.con" (should be ".com")
of cource this message will be stayed on the Exchange smtp queue and reply back with NDR to the sender, but during this period(stay in the queue),
other email also start to stay in the queue. Normal email process delays few mins because of the wrong email.
I've tested this case in the two quite different environment and got a same result.
If you are Exchange admins, please let me know if you can duplicate the issue.
I'd like to resolve this issue. Only one worng email shouldn't be affected to others, I believe.
Thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Service Packs should NOT be considered an optional installation. In the current security environment you should deploy them as soon as possible. That particularly service pack is well over 12 months old and is considered rock solid and would strongly advise that you install it as soon as you can.
You will also find it difficult to get support within the community as you are using a product that is over two years old and the service pack does make changes and fix problems within Exchange. I cannot even remember what it is like to work on an Exchange 2003 SP1 machine.
The behaviour that you are seeing with Exchange is not normal behaviour. Therefore you have to look at what is different from a conventional installations. In this case you have two differences, neither of which you seem to want to do anything about...
1. The lack of service pack 2
2. The use of a non Exchange smart host.
Rule number one with IT troubleshooting is to rule out things.
As you are using a smart host and this is an issue with email delivery the first thing that must be tried is bypassing the smart host. When you are using a smart host as the next hop Exchange simply tries to deliver all email to that smart host. At the moment you cannot say 100% that the smarthost is not the cause of the problem.
You need to bypass the smart host and test again, because until you do all other tests are worthless.
Simon.
You will also find it difficult to get support within the community as you are using a product that is over two years old and the service pack does make changes and fix problems within Exchange. I cannot even remember what it is like to work on an Exchange 2003 SP1 machine.
The behaviour that you are seeing with Exchange is not normal behaviour. Therefore you have to look at what is different from a conventional installations. In this case you have two differences, neither of which you seem to want to do anything about...
1. The lack of service pack 2
2. The use of a non Exchange smart host.
Rule number one with IT troubleshooting is to rule out things.
As you are using a smart host and this is an issue with email delivery the first thing that must be tried is bypassing the smart host. When you are using a smart host as the next hop Exchange simply tries to deliver all email to that smart host. At the moment you cannot say 100% that the smarthost is not the cause of the problem.
You need to bypass the smart host and test again, because until you do all other tests are worthless.
Simon.
Simon is right, SP's are not optional. Not sure if you have or use Microsoft Gold support, they will not even talk to you if you are running Exchange 2003 SP1. SP2 is going to help out in the long run. And as I said before try delivering messages via DNS rather than through the smart host and see if there is a difference in performance.
ASKER
At this moment we have no issue for SP1, so there are no obvious requirements to upgrade to SP2.
I've switched smart host to IIS SMTP but situation not changed.
BTW,
When I manually removed the stay queued with retrying message because of "sending to non-existent domain", user recieved the following message.
--------
The following recipient(s) could not be reached:
'recipient@ezweb.ne.jo' on 2006/11/26 21:28
The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator.
<exchange.contoso.net #4.0.0 smtp;450 <recipient@ezweb.ne.jo>: Recipient address rejected: Domain not found>
--------
"ezweb.ne.jo" is the non-existent domain.
I think this is normal message, but why Exchange didn't reply back to user about this error immediately?
Doesn't make sense to retry sending to non-existent domain.
I don't want Exchange to hold this message in the queue. And I think this is not relevant with smart host settings...
Any idea?