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. Continue reading Using Office 365 Plan P with your Company’s Domain Name

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.

Continue reading 17 RFCs Every Email Admin should Know About

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.

Continue reading 4 Steps in Troubleshooting SharePoint’s outbound SMTP connections

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.

Continue reading Common SMTP Exploits – Part 1

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.

Continue reading Troubleshooting Email Messages using SMTP Headers

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.

Continue reading List of Message Tracking IDs for Troubleshooting

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.

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.

Continue reading Got relay? Using the Microsoft SMTP service

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. Continue reading Diagnosing Email Server Problems with the Windows Command Line

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.

Continue reading Debugging SMTP and TLS errors in Outlook