asked on

Are Exchange 2003 Event ID 3015 and SMTP 4.4.7 Errors Related?

Twice last week my Windows Small Business Server 2003 daily performance reports listed an error I haven't seen before. Specifically, it listed an MSExchangeTransport Event ID: 3015 error with a single occurrence. The occurrence in question was an email message sent to a user account at sbcglobal.net.

I researched the error, and most of the documentation I found indicated the issue required using WinRoute to track routing groups or a bad pointer record. I confirmed with the ISP (Time Warner) that the server's PTR and Reverse DNS records are properly configured. Further, the domain is not listed on any spam/block lists I could find. There really aren't any routing groups in place, that I'm aware of, because this is a simple SBS 2003 setup.

Other information indicated the Microsoft Exchange MTA Stacks may be the culprit (if it's stalled). So I checked the server's MTA Stacks service. It was Disabled. So I set it to Automatic and dismounted and mounted the Exchange store. I'm still unable to send email from this domain to Bellsouth.net email accounts.

Then today staff began experiencing difficulty sending email to Bellsouth.net addresses. Those messages generate the following DNR report:

The following recipient(s) cannot be reached:
Persons Name (personsname@bellsouth.net) on 5/22/2008 11:46 AM
Could not deliver the message in the time limit specified. Please retry or contact your administrator.
<mydomain.com #4.4.7>

Are these errors related? Why might this server be experiencing Exchange routing/delivery issues out of the blue?

Stacy Spear

Have you checked your DNS? It seems that Bellsouth is not liking you guys and probably sbcglobal as well since they keep rejecting the connection and then it timed out.

Have there been any changes on servers, ISPs, etc that would have changed anything?

JayneCobb

ASKER

No changes, not listed on any spam or blacklists that I can tell, and DNS seems to be OK. But, I have the ISP researching the issue and the ISP admits to "sometimes having trouble with Bellsouth RADIUS rejecting email" or something like that. In the interim, I'm trying to confirm it's not somethin on my (server) end.

Stacy Spear

If you are sending mail through your ISP server, verify that they are not blacklisted. Had that issue with one particular 1and1 server about a year ago.

JayneCobb

ASKER

Not blacklisted.

The ISP says my HELO ELO doesn't match. The SBS 2003 server, when you telnet to port 25, returns acme.com (for example), whereas the Reverse DNS PTR is set for mail.acme.com (and that's what DNS is set for). How can I change that setting in SBS 2003?

ASKER CERTIFIED SOLUTION

Stacy Spear

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Stacy Spear

Are you relaying through your ISP's server or is your server the only one receiving your mail? If they are the mx host listed, then you should send your outgoing mail to them.

JayneCobb

ASKER

Darkstar,

I reran the Email and Internet Connection Wizard and specified the email domain as mail.acme.com. As a result, when opening the Advanced Delivery window (following your instructions) the Fully-qualified domain name reads mail.acme.com (with the actual real domain name properly listed).

Do I still need to enter that value (mail.acme.com) in the masquerade box?

Thx,

JayneCobb

ASKER

I have the server set to use DNS for outgoing messages. Thus, I don't believe I'm relaying. I do have a message in to the ISP asking if they support smart host configurations. In the event they do, I believe I can safely switch from using DNS to using smart host and entering the ISP's mail server IP address, no?

Stacy Spear

No the wizard did it. If you post up your @domain.com info, I can check if the ISP is taking long. Or you can check by going to mxtoolbox.com and see if it has your server as the MX or the ISPs. If it is the ISPs listed, you need to use a smart host and send all mail to them.

JayneCobb

ASKER

Darkstar3d,

First, thanks for your continued assistance. I appreciate it.

Second, I had been using DNSStuff to check the MX and reverse DNS PTR, but I went ahead and tried MX Toolbox. When I type in the domain name acme.com, MX Toolbox returns mail.acme.com with a preference of 10 and the correct IP address (the IP address provided by the ISP for use by this server).

Running the MX Toolbox diagnostics showed the server connect time as good, that it's not a relay, and a not good transaction time of 10.2 seconds. The session transcript read as follows:

HELO mxtoolbox.com - DIAGNOSTIC TEST - See http://www.mxtoolbox.com/Policy.aspx
501 5.5.4 Invalid Address [5046 ms]
HELO mxtoolbox.com
250 mail.acme.com Hello [64.20.227.131] [31 ms]
MAIL FROM: <test@mxtoolbox.com>
250 2.1.0 test@mxtoolbox.com....Sender OK [31 ms]
RCPT TO: <test@mxtoolbox.com>
550 5.7.1 Unable to relay for test@mxtoolbox.com [5046 ms]
QUIT
221 2.0.0 mail.acme.com Service closing transmission channel [31 ms]

Stacy Spear

dnsstuff.com is good, but cost $ after a few tries. :) Had to stop sending folks there.

Can you retry to send to that bellsouth.net address again to see what happens?

JayneCobb

ASKER

Currently I can't send to bellsouth.net addresses, but I'm told by my current ISP that I may have to call AT&T and tell them I made the change to get removed from its internal block list. I'll update this thread once I make that call.

JayneCobb

ASKER

The issue was apparently twofold. AT&T apparently felt that, since the email header acme.com didnt match the RDNS PTR of mail.acme.com, it wouldnt accept our email (without so much as a block or NDR message indicating that was the case). And, AT&Ts servers arent smart enough to monitor an address for changes; it just blocks you, thereby requiring a manual removal/update request. Fun stuff.

Stacy Spear

Good deal. AT&T just sucks in general though, not just there!

sswlewnix

JayneCobb,

I am having this same problem with our domain. Who did you contact at bellsouth/at&t that actually helped you resolve this. All I get is people that redirect me to complete an online form to take our domain off of the blacklist. We are not blacklisted, however.

frabru

I am having the same problem. I made all the changes suggested on the DNS till mxtoolbox looks ok. Still same problem, only fails with bellsouth.net. I've contacted bellsouth_unblock@abuse-att.netadministrator three times so far with no response. we are considering using the legal dept. to send them a letter requesting an explanation. So far, this is terribly frustrating.

sswlewnix

frabru...Download smtpdiag from Microsoft and use it to test sending e-mail from your server to a bellsouth.net e-mail address. I got the feedback that our ip address had been blocked due to abuse. It also gave an e-mail address or website to use to notify Bellsouth that you had been blocked incorrectly. Once I went through this process, they had us off the list in less than 1 day.

frabru

Thanks sswlewnix. The SMTPDIAG revealed information that neither the troubleshooting assistant or mxtoolbox revealed. It seems that the error was a 550, block, but the exchange error logs pointed to 447, delayed delivery. I have checked all spam list and we are clean, so problably these guys are using their own list. Also, the place to request removal is http:// att.net/blocks. I'm still waiting to see if this is the final solution.

(I have changed my mail server for MAIL and the user for USER

Searching for Exchange external DNS settings.
Computer name is MAIL.
VSI 1 has the following external DNS servers:
There are no external DNS servers configured.
 
Checking SOA for bellsouth.net.
Checking external DNS servers.
Checking internal DNS servers.
 
Checking TCP/UDP SOA serial number using DNS server [192.168.2.201].
TCP test succeeded.
UDP test succeeded.
Serial number: 2008021401
SOA serial number match: Passed.
 
Checking local domain records.
Starting TCP and UDP DNS queries for the local domain. This test will try to
validate that DNS is set up correctly for inbound mail. This test can fail for
3 reasons.
    1) Local domain is not set up in DNS. Inbound mail cannot be routed to
local mailboxes.
    2) Firewall blocks TCP/UDP DNS queries. This will not affect inbound mail,
but will affect outbound mail.
    3) Internal DNS is unaware of external DNS settings. This is a valid
configuration for certain topologies.
Checking MX records using TCP: MAIL.com.
  A:     MAIL.com [192.168.2.253]
  A:     MAIL.com [192.168.2.201]
Checking MX records using UDP: MAIL.com.
  A:     MAIL.com [192.168.2.201]
  A:     MAIL.com [192.168.2.253]
Both TCP and UDP queries succeeded. Local DNS test passed.
 
Checking remote domain records.
Starting TCP and UDP DNS queries for the remote domain. This test will try to
validate that DNS is set up correctly for outbound mail. This test can fail for
3 reasons.
    1) Firewall blocks TCP/UDP queries which will block outbound mail. Windows
2000/NT Server requires TCP DNS queries. Windows Server 2003 will use UDP
queries first, then fall back to TCP queries.
    2) Internal DNS does not know how to query external domains. You must
either use an external DNS server or configure DNS server to query external
domains.
    3) Remote domain does not exist. Failure is expected.
Checking MX records using TCP: bellsouth.net.
  MX:    gateway-f1.isp.att.net (10)
  MX:    gateway-f2.isp.att.net (10)
  A:     gateway-f1.isp.att.net [204.127.217.16]
  A:     gateway-f2.isp.att.net [207.115.11.16]
Checking MX records using UDP: bellsouth.net.
  MX:    gateway-f1.isp.att.net (10)
  MX:    gateway-f2.isp.att.net (10)
Both TCP and UDP queries succeeded. Remote DNS test passed.
 
Checking MX servers listed for USER@bellsouth.net.
Connecting to gateway-f2.isp.att.net [207.115.11.16] on port 25.
Received: 
550-7x.1xx.4x.2xx blocked by ldap:ou=rblmx,dc=att,dc=net
550 Error - Blocked for abuse. See http://att.net/blocks
 
 
Error: Expected "220". Server is not accepting connections.
Failed to submit mail to gateway-f2.isp.att.net.
Connecting to gateway-f1.isp.att.net [204.127.217.16] on port 25.
Received: 
550-7x.1xx.4x.2xx blocked by ldap:ou=rblmx,dc=att,dc=net
550 Error - Blocked for abuse. See http://att.net/blocks

Open in new window

sswlewnix

That is exactly the route I took once I got the smtpdiag tool!!! You should get it resolved quickly this way.

Stacy Spear

mxtoolbox/dnsstuff will show you generally WHY you have been blocked. The SMTPDIAG looks like a good tool to use, I normally just hand jam it in my self.

frabru

Looks like it is fixed. Something strange has happened. As I said before, I requested to have the blockage removed first from bellsouth_unblock@abuse.att.net, and eventually error 447 turned into 550. Then, I went to att.net/blocks. and I requested to get it removed. I t took less than 2 hours. Also, regarding spam blockages, I checked before all spam lists, including the tool on mxtoolbox and they were all negative.