Home » Posts tagged 'smtp'

Tag Archives: smtp

Advertisements

452 4.3.1 Insufficient System Resources – Continued Telnet Training

This is a problem that crops up fairly often if you have a lot of disparate Exchange servers out there without a solid monitoring solution in place. Very common for MSPs. Oh, and actually have somebody paying attention to those monitoring alerts. Nobody likes paying attention to monitoring alerts. There are reams of rules dedicated to keeping them out of sight in Outlook clients around the world. But that makes for an entirely separate topic/rant. The symptoms of this problem are that you’ll be getting reports from the end users that they don’t seem to be receiving any email, or at least any external email. But oddly enough sending out email is working just fine.

This is the point where a quick telnet test will focus you in on what is going on really fast. Continuing with what you learned from the post on Essential Exchange Troubleshooting – Send Email via Telnet you will want to telnet into the server from outside the organization. You may immediately get a response of:

452 4.3.1 Insufficient System Resources

But more likely you’ll receive a typical SMTP banner such as

220 myserver.contoso.com Microsoft ESMTP MAIL Service ready at Mon, 27 May 2013 08:19:44 -0700

If so then I recommend that you continue through with sending in an email via telnet. The next likely place that you’ll encounter this error is when you issue the RCPT TO: command to which you receive a response of

452 4.3.1 Insufficient System Resources

The fix for this is fairly simple. Check your Exchange server for low disk space usage on the partition where your queues reside, which will most likely be the partition with your Exchange installation. I find that most often what has eaten all of your space, in cases of single server Exchange 2007/2010 installations, is the IIS log files. When setting up your Exchange server it is a good idea to make sure that you have an archiving/recycling policy in place for your IIS logs to keep them from swallowing the entire partition over time. BES installations have the same problem as well with log files swallowing the drive.

The key phrase that you’ll want to keep in mind with this is “back pressure.” In a later post I’ll delve into this term.

More to the topic on hand, here’s an extra PowerShell fix for you to keep those IIS log files under control. It can also be easily customized for BES logs or other logging happy programs. Or even just keeping your temp files cleaned up regularly. You’ll want to set it to run as a scheduled task on a daily, weekly or monthly basis depending upon your organizations policies.

# CleanIISLogs.ps1
# Find and remove files older than $days
# Set $LogPath to where the IIS logs you want to recycle are kept
# 

$days = 31
$LogPath = C:\inetpub\logs\LogFiles\W3SVC1
# Find the target date
$startdate = Get-Date
$startdate = $startdate.AddDays(-$days)

# Clean the directory of log files older than the target date
Get-ChildItem -Path "$($LogPath)" -Recurse | where {$_.LastWriteTime -lt $startdate} | Remove-Item -Confirm:$false

Is this post helpful to you or is there something you would like me to go into greater detail on? Please let me know, thanks.

Advertisements

Essential Exchange Troubleshooting – Send Email via Telnet

One of the best tools available for troubleshooting mail flow issues is right at your fingertips. It is quick, simple, and only requires a little training to use effectively. I am always surprised at how very few Exchange administrators seem to use it. You can see some of this in action in my previous NDR troubleshooting post. So let’s delve into some of the basics of how to use telnet for troubleshooting your mail flow issues.

First off, it is a great way to see if your SMTP service is even available. If you cannot connect to it via telnet then you immediately know that you need to check on the health of your services and if that is ok then you most likely have a firewall or other networking issue. So to execute this basic check pop open a command prompt and run

telnet myserver.contoso.com 25

Substituting your server address and if you are troubleshooting an alternate port change the 25 to whatever port you are troubleshooting. The majority of the time it will be port 25 though. If you receive a successful connection you should be greeted by your mail server’s banner, probably something along the lines of below

220 myserver.contoso.com Microsoft ESMTP MAIL Service ready at Mon, 27 May 2013 08:19:44 -0700

This is also a good time to check whether you are seeing the correct server address in your banner. If you are seeing the internal address for myserver.contoso.local you will want to update this.

At this point you need respond with a HELO or EHLO command to start the SMTP conversation. What is the difference between them? HELO is for SMTP while EHLO is for eSMTP. In the context of sending an e-mail via telnet it won’t matter which you use but it mail be useful to use EHLO to see what verbs are being offered, especially if you are suspecting that there mail be a problem with eSMTP.

EHLO mail.alternatecontoso.com

You should receive a response similar to what is below

250-myserver.contoso.com Hello [4.3.2.1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH NTLM LOGIN
250-8BITMIME
250-BINARYMIME
250 CHUNKING

If you have seen all of the above then so far so good. Your routing is good (assuming you aren’t being routed to the wrong SMTP server, but if you are and you don’t know it then you have bigger problems), your firewall configuration is correct and your hub transport is listening. Also note from the verbs sent above you can see that this service supports TLS and authentication as you can see in the STARTTLS and AUTH NTLM LOGIN verbs.

Now we want to start sending an email to someone on this server. Most likely your postmaster account since you are just testing your mail flow.

MAIL FROM: someone@alternatecontoso.com

You should receive a Sender OK response. If not then you’ll know that you need to look into sender permissions.

250 2.1.0 Sender OK

We need to specify who we are sending to

RCPT TO: postmaster@contoso.com

Here you should receive a Recipient OK response. This is the part where the conversation is most likely to break down and you will get an error code that you can start working with.

250 2.1.5 Recipient OK

So far so good, now we can send the actual email. Start off with the DATA command

DATA

And the server will be ready to receive your input. You can get as fancy or as simple as you like here but once you are done with the message use a . to end the mail input

354 Start mail input; end with <CRLF>.<CRLF>
.
250 2.6.0 <53ea1be2-3d1a-4856-8bdf-3c576c14cfc0@mail.contoso.com> [InternalId=47975] Queued mail for delivery

Assuming everything is still going well you should see either a queued mail for delivery or a spam rejection, depending upon how strict your spam filter is. You also may get an error message that would be worth researching as well. If everything is still going well you can close out the conversation.

QUIT
221 2.0.0 Service closing transmission channel

This is all for sending an email similar to how an anonymous server on the Internet would send an e-mail. There are a few variations that you will want to be aware of as well though. The first is for testing relaying. When you get to the part where you input the recipient you will input a remote server recipient.

RCPT TO: foreignemail@externalserver.com

If you are NOT wanting the server to relay the expected response would be

550 5.7.1 Unable to relay

This is a good thing as you do not want open relays sitting around. But on the other hand if this is an internal connector that is supposed to be relaying then you could have a permissions problem on your hand.

The other method that you would normally use telnet testing for is authentication. This is a bit more complex. After your HELO/EHLO command you will issue

AUTH LOGIN

To which if basic authentication is supported you will receive a response of

334 VXNlcm5hbWU6

This gibberish is actually a base64 encoded response that says “Username:”. The expected response to this is a base64 encoded username. An online utility I recommend is at this site which is pretty simple for encoding/decoding base64 message. So translate the username you are attempting to use into base64 and respond with that. I responded with “logon” encoded.

bG9nb24=

You should receive a response of

334 UGFzc3dvcmQ6

Which translates to “Password.” So now you need to response with the account’s password encoded in base64. My response was “My simple password”

TXkgc2ltcGxlIHBhc3N3b3Jk

You should now receive an Authentication successful message

235 Authentication succeeded

And you can continue with the rest of your steps of sending an email.

Was this post helpful? Do you have any topics you would be interested in seeing me cover in a later blog post? Just leave your suggestion in the comments below or shoot me an email.

Outlook pulling the wrong user’s mailbox?

Recent problem I ran into at a client’s site was that when they were attempting to setup an Outlook profile for a specific user it would keep on pulling a different user’s mailbox. Also same thing happened when they pulled the e-mail from the global address list, though oddly enough if done from a Blackberry it was just fine. Checking the two mailboxes involved in Exchange 2007 yielded no wrong information. All the names and aliases were correct. So to dig deeper I broke out adsiedit.msc. Pulling up the user’s properties and checking the mail property showed that both accounts had the exact same e-mail address. A swift change of that to the proper smtp address corrected the problem immediately on all accounts.

Troubleshooting 554 Relay Access Denied NDRs

This week I was called up by a former employer to come in and check out their Exchange 2003 server. They had been having problems with a few domains rejecting their e-mails for the past few weeks and what made it a big problem was that one of the domains was their largest customer. Not a good scene there. They were receiving several NDRs of which the most prominent was something like <mail.domain.com #5.7.1 smtp;554 5.7.1 foo@otherdomain.com: Relay access denied> as well as some from another domain referencing authentication. I don’t have it in front of me so unfortunately I can not quote it. Doing some research I found that there was not much information on troubleshooting this and related problems even though there were lots of people asking. So I am putting together a quick little guide based off how I came to a resolution. Your results may vary.

E-mail problems generally break down to two types. Either you are having DNS problems, or you have a misconfigured server. First thing to do of course is to narrow down whether the problem is on your end or if it is on their end. Generally one would suspect the problem to be on their end when it is only a couple of domains giving you a problem, but that isn’t always the case. Easiest way to narrow it down is to break out the command line utilities. First verify that you are using the same DNS as your Exchange server. This is very important otherwise it may skew the results of your test. Next off you need to find your problem domain’s mail server. You have several options for this. The lazy way is to go to MX Lookup Tool and put in the domain. It should return the mail servers for that domain. You’d be best off going with the first one. The site also has some interesting diagnostic utilities that you could run against your mail server as well as their own. The non-lazy method, and one you should learn anyhow, is using nslookup. Pop open your command line and run nslookup. Here’s the steps to go through to get the MX records for their domain.

> set type=mx
> problemdomain.com
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
problemdomain.com mail exchanger = 10 mail.problemdomain.com.

Authoritative answers can be found from:

There’s the mail server that you are working with. Sometimes there are more than one so start from the top and work your way down. Next up is we’re going to send an e-mail the archaic way, through telnet. Note that not all SMTP servers respond with the exact same banners and responses, though the codes should generally line-up. Open up a telnet prompt.

telnet>  open mail.problemdomain.com 25

Trying 64.24.111.68…
Connected to mail.problemdomain.com.
Escape character is ‘^]’.
220 mail.yourdomain.com ESMTP Sendmail 8.9.3/8.9.3; Tue, 27 Aug 2002 16:20:32 -0500

At this point you need to identify yourself as your mail server.

ehlo mail.mydomain.com

250-mail.problemdomain.com mail.mydomain.com [203.32.9.6] pleased to meet you
250-8BITMIME
250-SIZE 10000000
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP

Now it is time to identify who you are.

mail from:yourself@mydomain.com

250 Ok

Next is who you are e-mailing.

rcpt to:testaccount@problemdomain.com notify=success,failure

250 Ok

If you get a 250 Ok at this point then telnet will most likely complete successfully. Also if you get a  510 Bad user that is ok as well, since you are not getting a relay access denied which is what your Exchange server is getting when it communicates with this server. This means their server has passed the telnet test so you need to start digging into your server to fix the problem. If you get a 550 Relaying denied error though that is different. Time to modify the test. Change your DNS server to a known good external DNS server that resolves both forward AND reverse look-ups correctly. If it does not resolve reverse look-ups it is no good to you. Switch your machine over to that DNS server and run through the test against. If it is successful then you’ve tracked the problem down. Time to look at what DNS servers your Exchange is using. Or it may also be time to check on your own internal DNS servers, as they may not be resolving addresses correctly. If, though, you receive a failure from your telnet test with a known good set of DNS servers then things may be a bit more complex. Do a look up on whether your domain is in any Realtime Blackhole Lists (RBL). If it is then definitely check to see if you are running an open relay and get yourself off those lists fast. If not then you had best get on the phone with the admin over at problemdomain.com to find out if your domain has been blacklisted. Finally another thing to verify is your SPF record on your external facing DNS. Here is a site to help craft an SPF record.

For completeness here are the rest of the directions to finish sending your e-mail through telnet:

data
354 End data with <CR><LF>.<CR><LF>
Test e-mail
.
250 Ok
quit
221 Bye
Connection closed by foreign host.
telnet>

In case you were wondering at the client’s site it turned out the Exchange server was set up to use an external DNS server that was not resolving reverse look-ups. This was causing a few sites to return the 554 relay access denied NDRs.

Some other tools that may be helpful in diagnosing your problem:

SMTPDiag.exe

Exchange Best Practices Analyzer

%d bloggers like this: