My last question on these boards was a few years back and I got excellent and 
valuable advice, so thank you all again in advance for any help. Debora.
--
Our setup is SBS 2003 R2 std edition, with Exchange 2003.

We have just discovered that some emails are not being received by outside 
clients from different domains. Exchange shows the message as gone, BUT the 
recipient never gets it ! However it does NOT do this every time, as they 
receive email on other occasions.

I have added a SMTP "GlitchRetrySeconds" to the registry to see if that helps.

Q. Does anyone know of a similar problem like this, a fix or any advice?
--
Note: I have read that there was a problem in the past about SMTP servers 
and "greylisting" measures which caused the sent email to vanish and NDR's 
were not received either. Don't know if this is our problem.

I would start by using the message tracking center within exchange.  From 
there you can definitively determine when the message got delivered to the 
remote server and provide that information to their sysadmin.  If the 
message tracking system reports successful delivery then it is in the 
recipient's court to check their servers (and use similar tools) to see if 
the message was trashed automatically as spam or something similar.

You can't control if a remote machine decides not to generate NDRs or is 
using greylisting, but you *may* be able to take steps to reduce your "spam 
score" if you get more detailed information from the recipient's sysadmin as 
to the cause of any action that was taken along this line.

Beyond that, I have never seen the message tracking center lie.  If it says 
it successfully delivered a message then that usually means it did...and the 
problem occurred outside of our network.  Conversely if there was a problem 
delivering the message, that will show up in the tracking center as well 
(although that would usually generate an NDR as well) so you can pinpoint 
and fix the problem on your end.

Any which way you slice it, start with the MTC and move on based on those 
results.

-- 
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet!  Check it 
out! 
http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/threads
Addicted to newsgroups?  Read about the NNTP Bridge for MS Forums.

"Debora" <Debora@discussions.microsoft.com> wrote in message 
news:41CDC106-B8C5-4BF0-904C-FF564142A7E1@microsoft.com...
> My last question on these boards was a few years back and I got excellent 
> and
> valuable advice, so thank you all again in advance for any help. Debora.
> --
> Our setup is SBS 2003 R2 std edition, with Exchange 2003.
>
> We have just discovered that some emails are not being received by outside
> clients from different domains. Exchange shows the message as gone, BUT 
> the
> recipient never gets it ! However it does NOT do this every time, as they
> receive email on other occasions.
>
> I have added a SMTP "GlitchRetrySeconds" to the registry to see if that 
> helps.
>
> Q. Does anyone know of a similar problem like this, a fix or any advice?
> --
> Note: I have read that there was a problem in the past about SMTP servers
> and "greylisting" measures which caused the sent email to vanish and NDR's
> were not received either. Don't know if this is our problem. 

Good Afternoon

telnetting to the remote server usually gives some clues on what's
happening.

you recreate an smtp conversation with a message you know wasn't
received, assuming plain texto only, and see how the remote server
reacts to the content.

have a nice day
PLeite
-------------------------------------------

Em 06/04/2010 02:03 PM, Debora escreveu:
> 
> My last question on these boards was a few years back and I got excellent and 
> valuable advice, so thank you all again in advance for any help. Debora.
> --
> Our setup is SBS 2003 R2 std edition, with Exchange 2003.
> 
> We have just discovered that some emails are not being received by outside 
> clients from different domains. Exchange shows the message as gone, BUT the 
> recipient never gets it ! However it does NOT do this every time, as they 
> receive email on other occasions.
> 
> I have added a SMTP "GlitchRetrySeconds" to the registry to see if that helps.
> 
> Q. Does anyone know of a similar problem like this, a fix or any advice?
> --
> Note: I have read that there was a problem in the past about SMTP servers 
> and "greylisting" measures which caused the sent email to vanish and NDR's 
> were not received either. Don't know if this is our problem.

On Fri, 4 Jun 2010 06:03:02 -0700, Debora
<Debora@discussions.microsoft.com> wrote:

>My last question on these boards was a few years back and I got excellent and 
>valuable advice, so thank you all again in advance for any help. Debora.
>--
>Our setup is SBS 2003 R2 std edition, with Exchange 2003.
>
>We have just discovered that some emails are not being received by outside 
>clients from different domains. Exchange shows the message as gone, BUT the 
>recipient never gets it ! However it does NOT do this every time, as they 
>receive email on other occasions.
>
>I have added a SMTP "GlitchRetrySeconds" to the registry to see if that helps.
>
>Q. Does anyone know of a similar problem like this, a fix or any advice?


In addition to Cliff and Pedro's responses, I would check your outside
IP if it's on a blocklist at www.mxtoolbox.com.

Ace

This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.

Thank you all for quick responses and advice.
I will take this advice and endeavour to setup and check the 'tracking' of 
e-mails as a first step. We only have a limited content 'logs' in place at 
present.

Taking Ace's comments I checked the blacklist via mxtoolbox and found we are 
on 1 blacklist out of 105 checked against. "< Your ISP BT-UK-AS BTnet UK 
Regional network/AS2856 is UCEPROTECT-Level3 listed for hosting a total of 
24403 abusers.
Return codes were: 127.0.0.2 >" This is a new field for me, but will also 
investigate what that means for the company.

Thanks again to all who took the time to comment. Debora x.

"Ace Fekay [MVP - Directory Services, MCT" wrote:

> On Fri, 4 Jun 2010 06:03:02 -0700, Debora
> <Debora@discussions.microsoft.com> wrote:
> 
> >My last question on these boards was a few years back and I got excellent and 
> >valuable advice, so thank you all again in advance for any help. Debora.
> >--
> >Our setup is SBS 2003 R2 std edition, with Exchange 2003.
> >
> >We have just discovered that some emails are not being received by outside 
> >clients from different domains. Exchange shows the message as gone, BUT the 
> >recipient never gets it ! However it does NOT do this every time, as they 
> >receive email on other occasions.
> >
> >I have added a SMTP "GlitchRetrySeconds" to the registry to see if that helps.
> >
> >Q. Does anyone know of a similar problem like this, a fix or any advice?
> 
> 
> In addition to Cliff and Pedro's responses, I would check your outside
> IP if it's on a blocklist at www.mxtoolbox.com.
> 
> Ace
> 
> This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
> 
> Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
> 
> Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
> Microsoft Certified Trainer
> Microsoft MVP - Directory Services
> 
> If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.
> .
> 

On Tue, 8 Jun 2010 08:44:05 -0700, Debora
<Debora@discussions.microsoft.com> wrote:

>Thank you all for quick responses and advice.
>I will take this advice and endeavour to setup and check the 'tracking' of 
>e-mails as a first step. We only have a limited content 'logs' in place at 
>present.
>
>Taking Ace's comments I checked the blacklist via mxtoolbox and found we are 
>on 1 blacklist out of 105 checked against. "< Your ISP BT-UK-AS BTnet UK 
>Regional network/AS2856 is UCEPROTECT-Level3 listed for hosting a total of 
>24403 abusers.
>Return codes were: 127.0.0.2 >" This is a new field for me, but will also 
>investigate what that means for the company.
>
>Thanks again to all who took the time to comment. Debora x.

Glad it helped, yet sorry to hear you are on a blocklist. The results
should show you how to get off them.

If you have any other questions, please feel free to respond.

Ace

Hi,

Thanks for your post and also thanks for others' good suggestions.

Common Scenarios 
=================
The following are common scenarios we see in support calls. As stated before, this list does not cover all possibilities, but provides a guide you can use to troubleshoot your incident. 

"	Blacklisting 
o	If your server has been reported sending spam, either directly or through unauthorized relay, then your server is probably blacklisted. If so, you will need to take the appropriate steps to 
secure your environment and contact the individual block lists to be removed. Microsoft has no control over 3rd party blacklists. 
o	You can check your server's status in several places. Examples include http://mxtoolbox.com/blacklists.aspx and http://openrbl.org 
o	Some blacklists may block by entire IP address ranges. Your server may be included in the range. 
o	An alternative is to relay your company's email through a 3rd party provided smart host. Email for your domain will not originate from the blacklisted IP address.


"	 Connection Filtering 
o	Your email domain or individual IP address may be explicitly blocked by the remote server without the use of online blacklists. 
o	You will need to contact that organization to find out why. 
o	You can relay mail through a smart host if available.


"	Improper DNS resolution of Remote Server 
o	It is possible that the remote domain is not blocking you at all, but that you are not even connecting to the correct server in the first place. 
	"	You may be using a forwarder with a bad MX record for the remote domain. This can be configured in both the DNS management console under the server properties and on the 	
		SMTP virtual server properties in Exchange. 
	"	You may be hosting an improper MX record for that domain (i.e. you may have created a zone in your DNS environment to hold it) 
	"	You may have cached an invalid response. Flush your DNS cache and try again. 
	"	Make sure that your hosts file is clean of invalid mappings to the remote server.
o	You can verify the actual MX record for the remote domain by using http://www.checkdns.net/quickcheck.aspx and http://dnsstuff.com/ 
o	You determine the IP address you are trying to connect to either in the SMTP logs or through a netmon trace.


"	Port 25 blocked at the remote site 
o	Test this with a telnet to the remote IP on port 25 
o	For information on how to do this, see: http://technet.microsoft.com/en-us/library/aa995718.aspx 
o	Telnet will also tell you where you are failing in the SMTP communication, assuming the issue is not regarding TCP/IP connectivity


"	Maximum Transmission Unit (MTU) and Black hole Routers 
o	A black hole router may exist between the SBS server and the remote mail server. 
o	If the SBS server is sending traffic that must be fragmented, but no ICMP control packet reaches SBS to let it know, then the traffic will be dropped without our knowledge. 
o	This can be proven with a simple ping test: ping remoteserverip -f -l 1472 
o	For more information on using ping to test MTU, see: http://support.microsoft.com/default.aspx?scid=kb;EN-US;159211


"	PTR Record 
o	If the PTR record does not point your server's IP address to its properly registered name, certain organizations checking for this will drop your connection. 
o	If you are planning on hosting multiple email domains from the same Exchange server on a single public IP, make sure you are allowed by your ISP to have multiple PTR records for the 
same IP address. If not, then the domain missing the record may be blocked occasionally. 
o	PTR records are created by and typically maintained by your ISP. They own the IP address that you have been assigned and should be the first point of contact if you are having problems 
with a record. 
o	Unlike A records, PTR records are not hosted by your DNS registrar; nor are they hosted by you even if you manage your own DNS namespace. 
o	Web sites you can use to check your PTR record include http://www.checkdns.net/quickcheck.aspx and http://dnsstuff.com/


"	Sender ID 
o	If you are participating in the Sender ID Framework and have registered an improperly configured SPF (Sender Policy Framework) record, then you may be rejected by any mail server that 
checks this. 
o	If you are unsure of an existing SPF record or need to create a new one for your domain, visit the Sender ID Framework SPF Record Wizard: 
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard


"	Grey Listing 
o	If your queues are building due to incompatible retry intervals with the remote mail server, try adjusting the glitch retry interval: http://technet.microsoft.com/en-us/library/aa998772.aspx

More information here:

What to Check When Exchange Cannot Send Email to Certain Domains
http://blogs.technet.com/sbs/archive/2008/01/03/what-to-check-when-exchange-cannot-send-email-to-certain-domains.aspx



Hope this helps.


Best regards,
Robbin Meng(MSFT)
Microsoft Online Newsgroup Support
==================================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
==================================================================