 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 4.4.7 Message Delayed Exchange 2003 SBS</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/447-message-delayed-exchange-2003-sbs/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/447-message-delayed-exchange-2003-sbs/</link>
	<description></description>
	<lastBuildDate>Wed, 22 May 2013 18:27:48 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: smahaf</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/447-message-delayed-exchange-2003-sbs/#comment-49544</link>
		<dc:creator>smahaf</dc:creator>
		<pubDate>Thu, 01 Dec 2005 03:24:19 +0000</pubDate>
		<guid isPermaLink="false">#comment-49544</guid>
		<description><![CDATA[Hi I had a similar problem with our Exchange 2000 server what I found was companies like AOL do not accept emails from unknown servers.... you can telnet on port 25 to an AOL server (do a nslookup get the ip and telnet to it) and it displays  a message saying mails from unknow sources is not accepted.... to get around this you can configure your server to use a Smarthost ( all your emails are sent to the Smarthost for delivery) the smarthost is know on the Internet so compaies like AOL will except the emails.

Try this link for more info

http://www.christopherlewis.com/ATT_SMTP_Config.htm


Thanks

Steven Mahaffey

]]></description>
		<content:encoded><![CDATA[<p>Hi I had a similar problem with our Exchange 2000 server what I found was companies like AOL do not accept emails from unknown servers&#8230;. you can telnet on port 25 to an AOL server (do a nslookup get the ip and telnet to it) and it displays  a message saying mails from unknow sources is not accepted&#8230;. to get around this you can configure your server to use a Smarthost ( all your emails are sent to the Smarthost for delivery) the smarthost is know on the Internet so compaies like AOL will except the emails.</p>
<p>Try this link for more info</p>
<p><a href="http://www.christopherlewis.com/ATT_SMTP_Config.htm" rel="nofollow">http://www.christopherlewis.com/ATT_SMTP_Config.htm</a></p>
<p>Thanks</p>
<p>Steven Mahaffey</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: stevesz</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/447-message-delayed-exchange-2003-sbs/#comment-49545</link>
		<dc:creator>stevesz</dc:creator>
		<pubDate>Wed, 30 Nov 2005 23:19:32 +0000</pubDate>
		<guid isPermaLink="false">#comment-49545</guid>
		<description><![CDATA[It is unlikely your mail is being blocked for spam reasons.

As has already been mentioned make sure your nameserver contains a PTR record for your server. Take your IP address, and use DNSSTUFF to do a reverse lookup. If you have a PTR record, it will show it, if not, get one set for yourself. You will need to talk with the people who hold teh SOA record for your domain to get this taken care of.

This will, at least, resolve your AOL problems, though the mail may bounce of another reason, which would be articulated in the NDR.

The message you quote from sounds like a 4.4.7 error. This can be a funky one to resolve becaue it is likely the problem lays with the recieving domain. Early this year, I had a problem with a large, well known hotel chain, with mail sent to them often coming back with a 4.4.7. Turns out they were depending on the originating mail server to fail over properly when it could not reach their mail distribution server, which was hidden behind their firewall and held their primary MX record. There is a patch for Exchange 2K that should resolve this problem, but for that domain, it did not, which meant there was more to the problem than their distribution server being hidden and having to fail over to a secondary MX record which pointed to a server outside their firewall.

They had wonderful documentation about how it was all supposed to work, except it didn&#039;t, at least for us, and I siuspect a lot of other people as well. After a lot of back and forth, something changed, and the mail flowed freely. After talking with my primary local contact with the chain, she let on as how they were recieving a lot more e-mail now  dealing with hotel business than they had in the past.

The big thing is that you need to talk with the IT department on the other end and try to work things out. You may need to find someone higher than those in the trenches to force the needed changes, or to at least let them know there is a problem.

hAnother thing you might wish to do is to create an SPF record, which is simply a line of text, formatted in a specific way, that lets other servers know the mail is coming from you. A number of larger companies are checking for an SPF record now, and some may be rejecting mail based on teh non-existance of an SPF record. see http://spf.pobox.com for help.

Steve]]></description>
		<content:encoded><![CDATA[<p>It is unlikely your mail is being blocked for spam reasons.</p>
<p>As has already been mentioned make sure your nameserver contains a PTR record for your server. Take your IP address, and use DNSSTUFF to do a reverse lookup. If you have a PTR record, it will show it, if not, get one set for yourself. You will need to talk with the people who hold teh SOA record for your domain to get this taken care of.</p>
<p>This will, at least, resolve your AOL problems, though the mail may bounce of another reason, which would be articulated in the NDR.</p>
<p>The message you quote from sounds like a 4.4.7 error. This can be a funky one to resolve becaue it is likely the problem lays with the recieving domain. Early this year, I had a problem with a large, well known hotel chain, with mail sent to them often coming back with a 4.4.7. Turns out they were depending on the originating mail server to fail over properly when it could not reach their mail distribution server, which was hidden behind their firewall and held their primary MX record. There is a patch for Exchange 2K that should resolve this problem, but for that domain, it did not, which meant there was more to the problem than their distribution server being hidden and having to fail over to a secondary MX record which pointed to a server outside their firewall.</p>
<p>They had wonderful documentation about how it was all supposed to work, except it didn&#8217;t, at least for us, and I siuspect a lot of other people as well. After a lot of back and forth, something changed, and the mail flowed freely. After talking with my primary local contact with the chain, she let on as how they were recieving a lot more e-mail now  dealing with hotel business than they had in the past.</p>
<p>The big thing is that you need to talk with the IT department on the other end and try to work things out. You may need to find someone higher than those in the trenches to force the needed changes, or to at least let them know there is a problem.</p>
<p>hAnother thing you might wish to do is to create an SPF record, which is simply a line of text, formatted in a specific way, that lets other servers know the mail is coming from you. A number of larger companies are checking for an SPF record now, and some may be rejecting mail based on teh non-existance of an SPF record. see <a href="http://spf.pobox.com" rel="nofollow">http://spf.pobox.com</a> for help.</p>
<p>Steve</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jcan123</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/447-message-delayed-exchange-2003-sbs/#comment-49546</link>
		<dc:creator>jcan123</dc:creator>
		<pubDate>Wed, 30 Nov 2005 00:28:49 +0000</pubDate>
		<guid isPermaLink="false">#comment-49546</guid>
		<description><![CDATA[Agree with yuvaksi
On the exchange server be sure that it has a &quot;public name&quot; to be seen on the outside. Another thing that some receipint servers check for is the domain part of the sending user. So if you have configured say internal.local as you FQDN on your internal network and this is the default address for the users with exchange mailboxes, then this will be used as the sender address and the receipient server will reject this because it cannot resolve the domain name. Goto receipient policy in exchange and change the default setting to your external domain and run RUS to update all users.]]></description>
		<content:encoded><![CDATA[<p>Agree with yuvaksi<br />
On the exchange server be sure that it has a &#8220;public name&#8221; to be seen on the outside. Another thing that some receipint servers check for is the domain part of the sending user. So if you have configured say internal.local as you FQDN on your internal network and this is the default address for the users with exchange mailboxes, then this will be used as the sender address and the receipient server will reject this because it cannot resolve the domain name. Goto receipient policy in exchange and change the default setting to your external domain and run RUS to update all users.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 3/10 queries in 0.030 seconds using memcached
Object Caching 295/301 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-23 01:22:36 -->