You must have heard about Office 365 by now, the newly launched cloud service by Microsoft that offers Exchange Online and other Microsoft-hosted services such as SharePoint Online, Lync Online and Office Web Apps.  Before being dismayed however, Exchange administrators may want to first check out my arguments as to Why Office 365 is good for Exchange Administrators. In addition, those who have yet to explore Office 365 may want to take some time to read my earlier article on TheEmailAdmin titled A Closer Look at Exchange in Microsoft’s Office 365.

Despite its various merits however, I would caution companies to carefully consider their requirements and sign up for Office 365 based solely on their needs – and not be taken in by the hype.  But let’s assume for the moment that Microsoft’s Plan P with its 25GB of mailbox storage per user is a great fit for your small business, and you would like to shift your company’s Exchange onto Office 365.  Having made the transition to Plan P myself, I want to highlight some possible issues that you may encounter.

Transfer your domain to Microsoft

Businesses considering Plan P may be surprised to learn that it does not support the use of domain names in the same way that Gmail, its web-based email services competitor, does.  Google allows Gmail users to send out emails from multiple domains as long as they have been validated, which means that the Send field of your emails will show: yourname@yourcompany.com when sent from your Gmail-hosted account.  In Plan P however, businesses will have to transfer the entire domain name to Microsoft before they get the same result.  Failing to do so will see Plan P stuck to the default: yourname@yourcompany.onmicrosoft.com when sending out email from your Office 365 account – hardly something a business would want.

Depending on who currently hosts your domain name server and the kind of services hosted on your domain, this may represent a significant problem to some businesses.  This is compounded by the fact that existing companies would already have their own websites with their own hosting arrangements.  Finally, these websites may be running on PHP or other scripting languages not supported by Microsoft.  Thankfully, companies that already have their own web server for their corporate website have a relatively easy way out if they are willing to transfer their domain name hosting over to Microsoft.

The steps are:

1.  Transfer  your domain name to Microsoft (Admin: Management -> Domains -> Add a domain)
2. Use the DNS Manager and set the appropriate A record (www) back to your company’s web server

According to forum postings that I came across, this strange state of affairs came about because Microsoft did not consider Plan P businesses to require a “vanity” domain (yourcompany.com).  I have not tried Plan E yet, though it is my understanding that it does not compel the transfer of your domain name to Microsoft in this manner.

Configuring Plan P to host your own domain

As highlighted above, transferring their entire domain name hosting to Microsoft may not necessarily be an option for some businesses for various reasons.  For example, there may be a need to pipe emails through a spam filtering appliance or online service, or you may find Microsoft’s functional but rudimentary DNS manager (A and CNAME records only) inadequate for your needs.

Or like me, you may want to forward your emails through an archival service before channeling it into your inbox.  In this scenario, it is possible to forward your incoming messages to: yourname@yourcompany.onmicrosoft.com and still receive your mails.  When it comes to outgoing emails however, it would be more professional to have your email aliased as: yourname@yourcompany.com.  There is another way around it, though be warned that it is a more involved task than the earlier method.

The steps are:

1. Initiate the wizard to transfer your domain name to Microsoft (Just like above)
2. Stop the verification process before it is completed (Don’t click “Next”)
3. Change the email send address manually using PowerShell to update your Office 365 Exchange Server configuration

For the specific steps and PowerShell commands, IT Consultant Peter Meinl does an excellent job outlining the requisite steps his blog entry Changing the email send address in Office 365 without moving your domain.

Administrators new to PowerShell should be cautioned that it has some dependencies on additional software that you may need to install (the PowerShell installation will prompt you on them).  In a nutshell: Don’t expect a five minute procedure if doing it for the first time; factor in some time to install them.

Using Office 365 Plan P with your Company’s Domain Name

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Internet’s Request For Comment system may be one of the world’s best examples of rule by majority consent, as it is the de facto set of ‘laws’ for how the Internet (and all its associated protocols) works, and is essentially a collection of documents that ask the world ‘what do you think about this?’

With literally thousands of documents in the collection, defining standards, recommendations, best practices, and the occasional joke, anytime you want to know the why behind how something is done, you need look no further than the RFCs. While they are replicated on countless websites, the official repository is found at http://www.rfc-editor.org.

RFCs evolve over time, and earlier RFCs can (and often will) be superseded by newer ones. There are several RFCs that address how our email protocols and the associated DNS records should work, and as an email admin, you should be familiar with the lineage of all the major email RFCs. Even those which have been superseded usually contain useful information, as most new ones define enhancements to a protocol, as opposed to completely replacing it. Over 300 of the RFCs have something to do with email; fortunately you won’t need to know them all unless you want to program a new email application. Below you will find a summary of the seventeen RFCs that email admins should have at least a passing familiarity with, and links to the online documents should you wish to read further. All links will open in a new window/tab.

DNS

The DNS records that support email include MX records, PTR records, SPF and Domain Key records. Each record format is defined within these RFCs. Here are the main RFCs concerned with DNS.

rfc 974 Mail routing and the domain system (MX records)

rfc 4406 Sender ID: Authenticating E-Mail

rfc 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

rfc 4871 DomainKeys Identified Mail (DKIM) Signatures

SMTP

The Simple Mail Transfer Protocol has evolved multiple times throughout its history, but each newer RFC ensures backwards compatibility with its predecessor.

rfc 821 Simple Mail Transfer Protocol (SMTP)

rfc 822 Standard for the Format of Internet Messages

rfc 2821 Simple Mail Transfer Protocol (SMTP)

rfc 2822 Internet Message Format

rfc 5321 Simple Mail Transfer Protocol (SMTP)

POP3

The Post Office Protocol has gone through a few iterations. Currently we are up to v3. You can review the RFCs for the earlier versions if you’d like to, but here are the ones relevant to the current version.

rfc 1725 Post Office Protocol Version 3

rfc 1939 Post Office Protocol Version 3

rfc 2449 POP3 Extension Mechanism

rfc 5034 The Post Office Protocol Simple Authentication Mechanmism

IMAP

Like POP, IMAP has gone through several iterations. The current one is IMAPv4.

rfc 3501 Internet Message Access Protocol v4

Security

While there are several RFCs that address various security mechanism within email, here are some of the ones you have probably dealt with or will deal with in your duties.

rfc 1991 PGP Message Exchange Formats

rfc 2246 TLS Protocol

rfc 2595 Using TLS with IMAP, POP3 and ACAP

Being familiar with the RFCs helps you understand what goes on between client and server or between server and server, and also reveals just how products from diverse manufacturers, running on many different operating systems, can still interoperate, making the exchange of messages and files possible.

There are several others related to email; which have you found most useful?

17 RFCs Every Email Admin should Know About

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

This is a blog for email admins, but frequently email admins are called into troubleshoot systems that want to use our email systems to send and/or receive email. One of the more critical services that will want to use our email system, and that can be tricky to troubleshoot, is SharePoint.

Microsoft’s SharePoint server can generate a lot of email. Notifications of group assignments, permissions assignments, workflows, and alerts can all cause SharePoint to send email out, and most companies want this email going through their Exchange or SMTP relay, as opposed to going straight out to the Internet using the IIS SMTP service.

If you are engaged to troubleshoot email relaying from SharePoint, you will want to have an idea of where things are configured, how they can go wrong, and how to troubleshoot them. This post will start with the basics on the SharePoint server and work its way outward. Keep the SharePoint admin nearby, as some of these things may require them to show you settings within SharePoint or to make changes and test.

1. Check the basics; name resolution and connectivity
   Too many times have I seen hours burned troubleshooting obscure code or script files, only to find that DNS wasn’t set up properly or the firewall ACL that they were absolutely certain was in place, wasn’t. Assuming your company has a designated SMTP relay, get on the SharePoint Web Front End and make sure you can resolve the name, ping it, and connect to it on TCP port 25 using TELNET or TCPING.
2. Make sure the SMTP relay will accept email from the SharePoint server
   If you aren’t sure how to do that, you want to have the TELNET executable on your server, and you can follow the steps in this post. Make sure that you see a 221 after your QUIT. If you are using Exchange as your relay, and it has not be set up to support unauthenticated connections internally, check out this post for the steps to add a listener for your SharePoint server. If you don’t see the 221, then your problem is probably on the SMTP server and not in SharePoint. Assuming you did get the 221, keep going.
3. Verify that AD is set up correctly
   SharePoint depends upon Active Directory for most of the information about users. Make sure that any users who are not receiving email have the correct email address populated in the properties of their email account. If they do not, correct that, ensure that AD replicates to any domain controllers in SharePoint’s site, and then have the SharePoint admin start a new crawl to get the updated information.
4. There are several ways to configure the SMTP server in SharePoint, but the easiest way to see how it is currently configured is to use SharePoint Central Administration. Have the SharePoint admin launch CA, browse to System Settings, then E-Mail and Tex Messages (SMS), and click Configure outgoing e-mail settings. Verify that the settings there are correct for your environment. Note that there is no place to configure authentication; your SMTP relay will have to accept unauthenticated connections.

If the testing in step 2 worked, your users’ email addresses are properly set up in AD, and your SharePoint server is properly set up in step 4, then try to send an email again, and watch the inbound SMTP queue on your mail server. Odds are the messages are making it from SharePoint to the mail server, and then failing. But the basics will solve more problems than not with SharePoint sending email, and the steps above will make sure you cover all of that.

4 Steps in Troubleshooting SharePoint’s outbound SMTP connections

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Ever since the inclusion of SMTP-AUTH the Simple Mail Transport Protocol was thought to be on its way to a more secure messaging protocol and with Microsoft’s inclusion of Secure Password Authentication that addressed security issues with Microsoft mail clients mail administrators could easily be lulled into a sense of security that truthfully doesn’t exist.

Email security is much more than simply protecting credentials and authentication. Though most people associate an attack on an email server with private or confidential messages being compromised, the risks of running an email server are much greater than that.

As email is still one of the most widely used methods of business communication, attackers find this to be an attractive target. Not only because they want to see what is in your company’s emails, but because they know that 1) email can open the door to many other resources and 2) people tend to let their guard down when it comes to using email.

Below you will see some of the most commonly used attacks against SMTP servers over time. While some may no longer be an effective means of compromising a system or network, they do show the trends in exploits that attackers use and being aware of them will help keep you on your toes when it comes to securing your servers against vulnerabilities.

Buffer overflows occur when a program is writing date to a buffer (an area that is used to temporarily hold data while it is being moved) and the size limit set for that buffer is maxed out causing an overflow of data. Usually this will crash the system but it can also be used to breach a system’s security.

A common method of exploiting this vulnerability on an SMTP server is to attack with an extremely long email addresses. In the parameter smtp.maxname, the maximum length of the email address is set. If the maximum is reached, the buffer overflow can allow the attacker to gain control through the MAIL FROM or RCPT TO commands.

Another commonly used buffer overflow attack against SMTP servers is against the HELO command where, depending on the server, a command containing more than the threshold of characters can crash the server and allow the attacker to take control using elevated privileges. Piggy back this with the fact that many admins still use the same administrator name and password on multiple systems and you can see where this type of attack can be far more serious than someone simply snooping through the bosses emails. This can lead to a complete network being compromised.

Of course, these only represent a fraction of the different commands that can be susceptible to a buffer overflow attack. Basically any string that overflows a container’s limit can technically be exploited and new vulnerabilities are found on a constant basis.

• Scanning the email server

When debugging mailing lists, the EXPN command can be quite useful as it shows information about the user accounts on a mail system. Of course the information used can also be quite beneficial to an attacker as well. Likewise, the VRFY does the same thing.

If an attacker is able to run these commands on your mail system then they can be used to map valid usernames and even create a hierarchy of user accounts that can be more productive to later attacks since they can also see who belongs to different mailing lists. If they want the IT accounts, they can look for a mailing list associate with this department. Names and accounts for C-level executives, secretaries, the HR department, etc can all be obtained through this vulnerability.

Not only will this give the attacker an employee directory, but it can also provide information about employees that can later be used in social engineering attacks against more lucrative targets within the organization.

With so many server tasks being automated, many admins may go through their careers never having used the EXPN or VRFY commands so they may be completely unaware that they are available. If these are not things that you use in the day to day operations of you or the IT staff then they should be disabled on any SMTP servers.

The second part of this series will look at abuse and relaying as well as how aliasing can be used to compromise your mail systems.

Common SMTP Exploits – Part 1

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you’ve been using Exchange and Outlook long enough to have used Outlook 2007 or earlier, and you are an email admin, then you’ve probably looked at the SMTP headers of a message to check out where it came from, what servers processed the message, X headers, etc. If you haven’t done that before, there is a wealth of information contained within an email’s header that you can access to glean more information about a message. You can see what servers processed the email from source to destination, the FQDN of the source server, any X headers added by antivirus or SPAM filter systems, and more. Of course, to use this information, you first have to see it.

In Exchange 2007, it was as easy to check the properties of a message (thereby exposing the SMTP header) as simply right-clicking a message, and then choosing properties. When I moved on to Exchange 2010, one of the first things I noticed was that that feature was missing. Right-clicking a message revealed a ton of options, but none of them displayed the properties of the message, and therefore showed me my SMTP headers. I never open email, preferring to use the reading pane in Outlook, so it took me ages to realize that there was a way to see my missing headers. In order to get to that information, you first have to double-click the message to open it, then you can click on the File menu, and there you will finally see your Properties. Since I hate actually opening a message, it was great to find another way to get there.

To add a one button access to the properties of an email, do this.

1. In Outlook, the upper left corner of the title bar is called the Quick Access Toolbar. Click the down arrow and then click More Commands
2. In the Choose Commands From dropdown list, select Commands Not in the Ribbon.
3. Select Message Options, then click Add.
4. Click OK and you’re done.

You have a new icon on the Quick Access Toolbar. Whichever message is highlighted, clicking that button will bring up the Message Options, and right in the middle of that dialog box is the SMTP headers, called Internet headers in Outlook.

So what can you do with this header? Well, a quick parse may be enough to show you whether the sending server domain name matches the alleged sender’s email address. It can also confirm whether or not the message passed through your SMTP relay, spam filters, etc. because it will show you every SMTP system that handled the message from the sender’s first mail relay to your mailbox server. Here’s what you can determine from the header of a message.

In the top section, which would be the last server to process a message, you will see your server identifying the message, and a timestamp for when the message was received. You may also see information about any anti-spam process that examined the message, like this. Note the SCL, which is the SPAM Confidence Level score.

X-SpamScore: -11
X-BigFish: vps-11(zz18a9K9371Pzz1202hzz8275bh8275dhz2dh2a8h5c0h668h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: KIP:(null);UIP:(null);IPVD:NLI;H:vps20022.example.com;RD: 6-11-22-74.example.com;EFVD:NLI

You will see another section, starting with “Received: from” for each intermediate server between the sender and your final receiving server. The last section that starts with “Received: from” will be the sender’s server, and from that you can see the FQDN of the server, the time stamp for when it received the initial email from the client, the from, to, cc, and reply to addresses, and client information like what type of email client the sender is using. You can also see the message id of the original, if the message you are examining is a reply.

X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 04341A86193B784594D95D83A1D972EE048F828392@VA3DIAXVS301.RED001.local
Thread-Index: AcvtdXfsEG6TQurjTQqb44HmHYINgwADRleg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994

Often, I have found the timestamps are very useful for troubleshooting delays, which actually turn out to be addressing user concerns about why an email may have taken so long to arrive. Frequently, a user’s perceived delay has been proven to be otherwise, using these headers. Just remember that some servers will stamp a message in UTC, while others will use their local time and display the offset in +/- hours. Also, there is nothing that guarantees a server is synched to NTP. They should be, but anomalies will appear from time to time.

Troubleshooting Email Messages using SMTP Headers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Part of every administrator’s troubleshooting effort is to review the log files whenever there are problems or issues with email communications. But it can be an extremely understated disappointment to attempt to bring up the log files only to find out that they do not exist. Or maybe logging was not turned on for some reason.

Assuming the log files exist and are also up to date then an administrator can review the log files searching for clues to help them decipher their current problem. However, although the message tracking ID numbers may be listed there is still the need to know what those message tracking ID numbers mean. A list of the majority of the SMTP message tracking ID numbers and their meanings will be included at the end of this article for your use.

Message tracking can be used to track all types of messages, including system messages and regular email messages that are being communicated from a non-Exchange messaging system, across your Exchange organization. An example of how message tracking can be useful is when an administrator needs to locate an email message that has failed to arrive in a recipients’ mailbox. It’s possible that the message is stuck in a connector’s message queue.

But before an administrator can begin to troubleshoot the failed communication of email messages they must first ensure that the message tracking capability is enabled for Exchange Server. By default, message tracking is not enabled. Each instance of Exchange Server that is to be managed should have message tracking enabled.

If an administrator is administering more than one Exchange Server then they can leverage System Policies to help them enable message tracking. If only one Exchange Server is being administered then message tracking can be enabled in Exchange System Manager. Be aware that, as with most logging capable system, when logging is running log files can grow very large on active systems. If your Exchange Server is a system that sees a high amount of communications then plan the location of the log files so that they will have room to grow.

Here are the steps to enabling message tracking in Exchange Server 2003.

1. Start the Exchange System Manager.
2. Navigate to the Server object to activate Message Tracking.
3. Right click on the server object.
4. Click Properties.
5. Select the General tab
6. Click the checkbox for Enable Message Tracking.
7. Verify the log file information is correct.

The default state is that log files which are older then seven days will be deleted.

Now, as I mentioned earlier in this article, I am including a list of the majority of the SMTP message tracking ID numbers and their descriptions.

List of Message Tracking IDs for Troubleshooting

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Every end user out there takes for granted that when they push the Send button that there will be no problem. And take for granted that when we go to read our inbox that there will be no trouble to download new messages. But, of course, we all know that sending and receiving email messages can be interrupted at any time. And as administrators we must be able to produce solutions as fast as possible.

If your organization is running Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, or Microsoft Windows Small Business Server 2003 and your end users try to send or receive email then they might run into one of the following scenarios:

• Exchange server does not accept Simple Mail Transfer Protocol (SMTP) messages from certain Internet domains.
• Exchange server cannot deliver SMTP messages to certain Internet domains.

An administrator can perform a reverse Domain Name System (DNS) lookup and find that the Exchange server that is sending the SMTP message cannot be resolved. They should then perform a network monitor trace and look for any NBT (NetBIOS over TCP/IP) queries before the Exchange server disconnects.

The sender will probably receive a non-delivery report (NDR) that contains the 5.5.0 error code. This code indicates a generic SMTP failure. The NDR will look similar to the following:

> Your message did not reach some or all of the intended recipients.
>
>       Subject:
>       Sent:    9/12/02 3:39 PM
>
> The following recipient(s) could not be reached:
>
> user@destination.com on 9/12/02 3:39 PM
> Your mail system could not find a way to successfully communicate with the destination system. Please notify your administrator. <Server.source.com> #5.5.0

Additionally error code: #5.5.4 “Transaction failed” might also be generated.

Administrators should also check the Windows Event viewer on the Exchange server that is sending the error message. They should look for an error message that contains event 4000 or event 4001. The error message will be similar to the following:

Event Type: Warning
Event Source: MSExchangeTransport
Event ID: 4000
Description: Message delivery to the remote domain ‘ destination.com ‘ failed for the following reason: SMTP protocol error.

This situation can occur if the destination SMTP server performs a reverse DNS lookup and if one of the following conditions is true:

• The IP address does not match the domain name that is used in the return address of the email message.
• A pointer (PTR) record does not exist or is invalid for the source SMTP server’s IP address.

An administrator may find themselves in a situation where email messages which are sent from one domain to another domain are not delivered. Suppose the originator of the email sent has a domain name that is used in the return address of the message such as originator.com. Once the message is sent and the destination SMTP server receives the message it will perform a reverse DNS lookup. If the destination SMTP server finds that the PTR record for the originator.com domain does not exist or is incorrect, it will not deliver the message.

Administrators should be aware that using a dynamic IP address with a network adapter connected to the internet may require a reconfiguration of the Exchange Server settings for proper routing of email messages. This may be necessary for the Exchange Server to route mail from the originator.com domain through an SMTP connector to a smart host.

If an administrator wants reverse DNS lookups to be performed on all connections then they can configure the Exchange server to reject incoming connections by specifying a domain name on the SMTP virtual server. Administrators can perform this operation by right clicking the SMTP virtual server, selecting Properties, then the Access tab and then looking under Connection Control.

Administrators can correct this problem by following the steps outlined below:

1. Confirm that the public DNS records that are hosted on your DNS server are correct. Verify that your DNS server has these settings:                             Ensure that an MX record for your domain points to a valid Host (A) record. The MX record for originator.com points to mail.originator.com. Therefore mail.originator.com is a valid email server.                                                      Ensure that the Host (A) record points to a valid IP Address. In my case, mail.originator.com points to 200.44.51.64.
2. Confirm that there is a valid PTR record for the Public IP address of every SMTP server or Exchange Server system that is sending email.

Troubleshooting Exchange and Unaccepted SMTP Domains

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Most companies need an internal SMTP relay at some point. Whether this is for alerting systems, or the scan to email features of their printers, or the “phone home” capabilities many hardware systems offer, the ability for an internal device to send an email to both your internal systems, and out to the world is often needed, and frequently either over, or under engineered. 

Microsoft includes an SMTP service with all versions of the Windows operating system, and the SMTP service is perfect for the job of taking all the non-Exchange based emails in your company and passing them through a single point without having to pass them through your Exchange system unless they are destined for an internal mailbox.

I have seen companies establish dedicated servers, or purchase third party applications, for what is really a very light-weight task that can be added to any available file server or other server with minimal resources. Let’s look at how to add the service, how to configure the service, and some considerations for its use.

Identifying the need

If you have printers with a scan to email feature, SANs or other vendor supported systems that want to email reports and alerts to the vendor, alerting systems that like to send SMTP messages about events, or anything else that needs to send email out to the Internet but that you don’t want to assign an Exchange CAL, then this service is for you.

Choosing which server(s) to use

The SMTP service is available on all versions of the server platform, and requires almost no RAM, CPU, or disk, so it can be installed on essentially any system you have. I like to use file servers, as they tend to have resources to spare (other than free disk space) and are in a central location. This is good, as you want this service to be available to your entire network. I like to deploy two systems, and set up DNS round robin so that the service is highly available. Of course, many older printer/scanners can only be pointed to an ip.addr, so if this is really critical, you need to set up a pair and use NLB.

Getting ready to install

If you are going to let your SMTP relay send mail directly out to the Internet, identify the external address your relay will be NAT’d to on your firewall. Establish an MX record with a weight of 99, and update your SPF record to include this system. If you are going to pass email through your content inspection system, get that internal ip.addr or FQDN, and ensure it is setup to accept mail from your relay.

How to install the service

In Windows 2008, the SMTP service is considered a feature. Here is how you add that. Open an administrative command prompt and run this command as a single line (wrapped to fit the column.)

servermanagercmd.exe -i web-metabase web-lgcy-mgmt-console
 rsat-smtp smtp-server [enter]

How to manage the service

To manage this feature, use the Internet Information Services (IIS) 6.0 Manager, which was added to your Administrative Tools menu when you installed the SMTP Service. In the 2008 SMTP service, the default configuration will NOT relay for any host, which is a good thing. We want to provide a service, but we don’t want to open the floodgates.

1. Right-click your server to access the properties.
2. On the General tab, the defaults should be acceptable for most uses, but you might want to enable logging so that you can see how your relay is being used.
3. Click the Access tab.
4. If you want to require authentication, click the Authentication button. However, since most printers won’t support that, you probably want to leave Authentication alone.
5. Click the Relay button. Notice that by default, no relay is allowed. If you are absolutely certain that this server is will not be abused, and you do not want to restrict relay, you can click the radio button for “All except the list below.” Do not do this on a system in the DMZ, or that has a static NAT assigned to it on the external interface of your firewall. Doing so would create an ‘open relay’ and we all know how bad a thing that is. I recommend that you add the individual addresses of systems you want to permit, or as a compromise, add your internal subnet(s.) This is less work than adding each individual machine, means new systems can start relaying mail without your involvement, and still ensures that your server won’t become an open relay to the world.
6. Click the Messages tab, and review the default limits on number and size of messages. Adjust to taste.
7. Click on the Delivery tab, and then the Advanced button. If you are going to let your SMTP relay send mail directly out to other MTAs on the Internet, fill in the FQDN of your system with a name that will map to the MX record you created in “Getting ready to install” section. If you are going to send email through another system that does anti-malware and content inspection (recommended) then fill in the “Smart host:” field with the ip.addr or FQDN of that system. Smaller business that use an ISP for email will want probably need to fill in the FQDN of their ISP’s relay here. Click OK.
8. If the upstream relay requires authentication, click the Outbound Security button, and set the appropriate credentials. If not, you are done.
9. Test your relay out, using the telnet process we covered in this article.

If all is well, your server should be sending emails like a champ. Remember, whether you assign it a dedicated NAT address on the firewall, or let it use the global, you will want to add that to your SPF records so that external systems will accept your email. And since email is something you should keep an eye on, make sure your egress filtering doesn’t allow all systems to send email directly out; only your SMTP relay and mail infrastructure should have that privilege.

Got relay? Using the Microsoft SMTP service

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

An essential skill for email administrators is being able to dive into the command line to troubleshoot email delivery and connectivity problems.  In this post I will explain some of the simple command line techniques you can use for diagnosing these email issues.

NSLookup

NSLookup is the command line utility for querying the Domain Name System (DNS).  Because email delivery relies so heavily on the Mail Exchanger (MX) records contained within DNS you need to know how to use it for verifying DNS configurations.

When someone reports a problem sending email to an outside party and you want to investigate it one of the first things you’ll need to determine is the name or IP address of their mail server.  This is the job of the MX record, which you can query using NSLookup.

Open a command prompt (Start -> Run, cmd.exe) and type “nslookup” and press Enter.  First test a few well known web addresses to make sure that your own DNS servers are working properly.

C:\>nslookup
Default Server:  UnKnown
Address:  192.168.0.1

> www.gfi.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
Name:    www.gfi.com
Address:  216.134.217.17

> www.theemailadmin.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
Name:    theemailadmin.com
Address:  69.89.31.227
Aliases:  www.theemailadmin.com

Now change the query type to MX by typing “set” and press Enter.

> set type=mx

Next type the domain name for the organization you are trying to send to, e.g. contoso.com.

> contoso.com

If their DNS zone exists, is correctly configured, and their name servers are responding, you should receive a response similar to this.

Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
contoso.com     MX preference = 10,
mail exchanger = mail.global.frontbridge.com

mail.global.frontbridge.com
internet address = 216.32.180.22

If there is a problem you may receive a response more like this.

*** UnKnown can't find contoso.com: Non-existent domain

When a successful response is received it tells us that they have one MX record with a preference of 10 (this only matters when there are more than one MX records), and that its name is mail.global.frontbridge.com.  Furthermore we can see that mail.global.frontbridge.com resolves to IP address 216.32.180.22.  This is the IP address we want to connect to for testing email connectivity.

Telnet

Telnet is the command line utility to use for testing connectivity.  Telnet allows us to connect to any IP address and TCP port to perform testing.

For Windows Server 2003 and earlier Telnet is already installed, but for Windows Server 2008 Microsoft took the standpoint that Telnet is potentially a hacking tool and so is not installed by default on new servers.  You can install it when necessary by launching an elevated privilege command prompt and running this command.

servermanagercmd.exe –i telnet-client

From a command prompt type “telnet [name/IP address] 25” and press Enter.  This tells Telnet to connect to the given name or IP address on TCP port 25 (the SMTP port).

At a successful connection you will see status code 220 (meaning Service Ready) followed by the welcome banner for the server (this will vary depending on the mail server software that they are running plus whatever customization the email administrator applies).

220 TX2EHSMHS026.bigfish.com Microsoft ESMTP MAIL
Service ready at Thu, 19 Nov 2009 12:44:27 +0000

Now it is time to learn how to issue basic SMTP commands using Telnet.  A simple SMTP session will contain these steps:

EHLO – Identifies the sending server (you).  You can also use HELO, but EHLO is widely supported.

MAIL – Identifies the sending email address.

RCPT – Identifies the receiving email address.

DATA – The contents of the email message itself.

So to test email to the contoso.com email server you can use this command sequence.

ehlo
250-TX2EHSMHS026.bigfish.com Hello [202.173.145.153]
250-SIZE 157286400
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250 CHUNKING
mail from: paul@exchangeserverpro.com
250 2.1.0 OK
rcpt to: name@contoso.com
250 2.1.5 OK
data
354  Go ahead
Subject: This is a test email
This is a test email
.
250 2.0.0 OK

Note how the message is sent after the DATA verb is issued, the data itself entered, and then a “.” (period) indicating the end of the data.

If there are any problems with this SMTP session the error messages that are returned by the server will indicate exactly what is going on.  For example, the server may return a message saying that message relay is denied, or that the intended recipient is not valid.  From this you can determine the next steps to take in troubleshooting the email problem.

Diagnosing Email Server Problems with the Windows Command Line

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Sending secure email often involves the process of also having to troubleshoot error messages related to TLS and SMTP in Outlook.

Transport Layer Security (TLS) is a cryptographic protocol used to encrypt traffic over networks such as the Internet. Use TLS encryption for servers that require basic authentication. With so much critical information such as usernames and passwords passing through your network, why take the risk that someone snooping could eavesdrop and pull out important corporate information? Implementing encryption and other security measures can help to protect your corporate jewels. The enforcement of security will require users to use the same encryption level that you set when they try to negotiate access to your network and servers. Without the same level of security, messages will be returned and non-delivery reports (NDR) will be generated.

Simple Mail Transfer Protocol (SMTP) is used for sending outgoing mail for both POP and IMAP clients and is well known for its vulnerabilities such as spoofing of emails.

To minimize your security exposure and to ensure that your corporate SMTP communications are protected you can start by implementing the Transport Layer Security protocol in the Exchange Server.

If you are like most email or system administrators you will be supporting both end users who work at corporate offices and also end users working from remote locations such as out of state offices or home offices.

Occasionally you will get a complaint from end users who are unable to send email but they can still receive email. After changing the SMTP addresses in their outgoing email servers you find that they are still not able to send email and that they are getting an error message such as the following:

“Verify the email address in your account properties. Server responded: 530
5.7.0. Issue a STARTTLS command first.”

The STARTTLS command takes plain text communications and provides a secure connection without having to use a separate port for encrypted communication. It is an extension to plain text communication protocols and makes a plain text connection become an encrypted connection such as a TLS or SSL connection.

The benefits to using STARTTLS include the ability to verify the identity of the client and/or server in an e-mail transmission. It can also be used to encrypt mail transmissions with or without the identity verified between two mail servers. And it provides the capability to authenticate a user for relaying through a mail server.

Now as previously mentioned, if for some reason a client is not able to send email and they are receiving an error message about having to issue a STARTTLS command first then a solution is to enable an encrypted Secure Socket Layer (SSL) connection for the SMTP server. You make this change in the account setup. Look for the advanced tab of the More Settings dialog box.

Another troubleshooting mechanism you can use is to turn on transport logging in Microsoft Outlook. This will allow you to log all communications between Outlook and many of the email servers that are out there. By reviewing the logs you will be able to identify any communication problems that might occur when using Outlook and email servers.

• You can turn on logging in Outlook by going to the Tools menu and clicking Options.
• Next, select the Other tab and then click on the Advanced Options button.
• You will get a check box labeled “Enable mail logging”.
• Put a check mark in the box by clicking on it.
• Then save your changes by clicking OK.
• Click OK again after you have returned to the main options.
• Finally exit Outlook and then restart it.

If your problem is that you are having trouble establishing a secure connection to Microsoft Exchange server it might be because you are trying to use a different port other than the default (SMTP) port 25. This may have happened if another administrator or an end user changed the default port by selecting the check box labeled, “This server requires a secure connection”. This will also affect other email servers that require a STARTTLS negotiation.

When Outlook 2000 is used to create a secure connection for SMTP it will issue a STARTTLS command which then starts the TLS handshake process for a connection using the default port 25. But this is not the same process for ports other than port 25.

A solution to this kind of problem is to upgrade to Microsoft Outlook 2002. After the upgrade the email client will be able to issue the STARTTLS command and initiate the negotiation process for a secure socket on a different port number that is not port 25.

Debugging SMTP and TLS errors in Outlook

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators