Emails stuck in Outgoig Queue
I'm a programmer trying to support Exchange :)
Emails are getting stuck in queue for outgoing for most recipients. But I can send to my MSN account wth no prblem. I assume because MSN is doesn't care about all the liittle things that some businesses do? Return for Exhange Sys Admin emial is: (editted for security)
Your message did not reach some or all of the intended recipients.
Subject:
Sent: 8/5/2004 8:43 AM
The following recipient(s) could not be reached:
name@myemail.com on 8/5/2004 9:44 AM
One or more mandatory argument(s) were missing from the recipient
The MTS-ID of the original message is: c=US;a= ;p=CompanyName.;l=APEXCHAN
I don't know where to begin...any thoughts?
Emails are getting stuck in queue for outgoing for most recipients. But I can send to my MSN account wth no prblem. I assume because MSN is doesn't care about all the liittle things that some businesses do? Return for Exhange Sys Admin emial is: (editted for security)
Your message did not reach some or all of the intended recipients.
Subject:
Sent: 8/5/2004 8:43 AM
The following recipient(s) could not be reached:
name@myemail.com on 8/5/2004 9:44 AM
One or more mandatory argument(s) were missing from the recipient
The MTS-ID of the original message is: c=US;a= ;p=CompanyName.;l=APEXCHAN
I don't know where to begin...any thoughts?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi
Just a thought - What version of exchange is it and what service pack? - you may need to install the latest service pack (if you do - read through the notes accompanying it, and make sure you have the server properly backed up)
Deb :))
Just a thought - What version of exchange is it and what service pack? - you may need to install the latest service pack (if you do - read through the notes accompanying it, and make sure you have the server properly backed up)
Deb :))
ASKER
Why would the non-current service pack cause to just stop sending mail? Doesn't seem logical...but I don't know.
Also, our domain name cannot be accessed or ping, but the Exchange server doesn't interact with the webserver, just uses the domain name. Could there be a link?
Also, our domain name cannot be accessed or ping, but the Exchange server doesn't interact with the webserver, just uses the domain name. Could there be a link?
ASKER
If you can't ping or connect to the domain name or IP, like www.mydomain.com, will email for that same domain name work?
ASKER
Here is the error when trying to send to my email address for this domain:
The following addresses had fatal errors:
myname@mydomain.com: 450 [TEMPFAIL] destination not valid within DNS
The following addresses had fatal errors:
myname@mydomain.com: 450 [TEMPFAIL] destination not valid within DNS
ASKER
Think I figured it out, Sprint cancelled our line and deleted the MX record. #%^$&$%^*
MicroTech, thanks for the point to TelNet
Thanks.
MicroTech, thanks for the point to TelNet
Thanks.
I had the same message today, but the problem that cuased the message was not an MX record.
It seems that some anti-spam software is now starting to use PTR records to validate the hostname of the sending server's IP address versus the hostname contained in the SMTP headers. If they do not match then they message is rejected immediately. This is the case in my domain where the internal (private) hostname of our exchange server is different from the registered hostname on our public DNS servers (also for our security purposes).
I am not aware of an easy way to remedy the situation without revealing our internal addressing.
It seems that some anti-spam software is now starting to use PTR records to validate the hostname of the sending server's IP address versus the hostname contained in the SMTP headers. If they do not match then they message is rejected immediately. This is the case in my domain where the internal (private) hostname of our exchange server is different from the registered hostname on our public DNS servers (also for our security purposes).
I am not aware of an easy way to remedy the situation without revealing our internal addressing.
ASKER