From: Ace Fekay [MVP - Directory Services, MCT] on
On Tue, 8 Jun 2010 08:44:05 -0700, Debora
<Debora(a)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
From: "Robbin Meng [MSFT]" on

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.
==================================================================