SEMblog

So you have setup your Exchange 2007 server and now wonder whether it works correctly.
The DNS changes are in place, the SSL certificate works, but how do you test it?

Or your server isn't working correct and you want to test it from an external host - but how can you do that quickly and easily?

A new tool from the Microsoft Exchange team, currently in prototype/development may well be something to help you. https://www.testexchangeconnectivity.com/ can currently test Autodiscover, Outlook Anywhere (which should work for Exchange 2003 and Exchange 2007), ActiveSync and inbound SMTP.
Inbound SMTP can obviously be used to test any server.

For the tests that require accounts, I would suggest configuring a test account which can be disposed of later, although Microsoft do state (on the "Is this secure" link) "

Passwords gathered using this tool are not stored by the server.  Passwords are encrypted in memory inside of the user's browser using a key only known to this server.  When passwords are transmitted to the server, they are encrypted using the server key and only transmitted to the server over a Secure Sockets Layer (SSL) connection.  As always however, it is recommend that you use a disposable test account for any testing done over the Internet."

The tool runs over SSL (using the same type of certificates available from http://CertificatesForExchange.com) so you should be able to use it from the Exchange server itself.
It does require the relevant ports to be open and information in the public DNS records, so no use for test environments that are not exposed to the internet and anything that is exposed will have to be secure. However for the final test before going live it is ideal.

https://www.testexchangeconnectivity.com/

This is another post in my serious of articles on why you shouldn't use certain features in Exchange, even though they are there. As with the other articles, the article does NOT tell you how to enable the feature in question.

The other articles in this series to date are:

• why you shouldn't enable the POP3 Server (http://blog.sembee.co.uk/archive/2008/03/03/71.aspx)
• why you shouldn't use the POP3 connector (http://blog.sembee.co.uk/archive/2006/09/25/28.aspx)
• why you shouldn't use a self generated SSL certificate (http://blog.sembee.co.uk/archive/2006/03/05/9.aspx)
• why you shouldn't put Exchange 2003 in to a DMZ (http://blog.sembee.co.uk/archive/2006/02/23/7.aspx)

For this article I am going to outline why logos in an email signatures are a bad idea. This also applies to stationery as well.

Why would you use a logo?

Almost certainly the desire to use a logo in the signature will come from either upper management or marketing. They are proud of the logo and want to see it everywhere, and see email as an extension of the marketing exercise. Often it will come after a name change, merger or new look launched. However I also call it a "boredom idea" as it is usually suggested when someone is looking for idea during a meeting on how to improve the company visibility (or some such nonsense) and cannot think of anything original.

Why you shouldn't use a logo

Trying to argue against the use of a logo in email, particularly if the request has come from a senior figure in the company can be an uphill battle. However the reasons for it are sound.

1. Makes the message larger, therefore increase the size of your Exchange store and the recipient's store.
   Every recipient will get a copy of the logo, on every message. If your logo is 10k, then every message you send is at least 10k, even if it has "hello" on it, and nothing else. You send ten messages to a client, that is 100k. 10 messages a day every day (which is not unusual) then that is 700k a week, which quickly builds up. 
2. It can increase the likelihood of your message being flagged as spam, or as least suspicious.
   Everyone will have been plagued by the image spam. Therefore if your email contains an image embedded in the message, then it could get flagged.
   
   If you are looking to have the image stored remotely to avoid that and the increase in size, then that will not help either. The image could be flagged as a web bug and get the message flagged as spam.
3. You cannot control how the message will be displayed at the other end, or what the recipient is using.
   If you are downloading the logo from a web page, then you are presuming that the recipient has access to the internet when the message is viewed. They may not.
   
   The recipient could be using a PDA or collecting email over a low bandwidth connection. They will not appreciate the additional bulk of your message and the logo just to have someone say "Thanks".
   
   Once you start moving away from plain text formatting you also have the problem of display at the other end. You cannot guarantee how it will look at the end, even whether the image will remain embedded in the message or appear as an attachment. Different clients will use different ways to render the message format - ask any web developers about the problems they have with getting a web site to look the same in the various browsers in use. 
   
   Finally, to use a logo that means you have to use one of the rich formatted messages - HTML or rich text. Plain text is out of the question.
   
   If you force the use of the logo at the server using a third party tool then any recipient of email sent using plain text may well find that the message format will be changed.
4. Do large companies send emails with logos?
   The final point to put across is how many large companies do you see using a logo? The answer will be none. Where a logo is used it will be something the sender themselves has done, not something that is being done centrally. It is only ever small companies that do these sorts of things - and most managers do not want to be seen as a "small company".

Logos in signatures is something that you should try and avoid where possible for the health of the server, and to try and ensure that your email is not blocked or be unwelcome by the recipients.

I have blogged in the past about the Windows Mobile emulator, as I have found it an excellent tool when testing new solutions, looking at problems and generally getting to grips with the mobile side of Exchange. It also means that I can leave my own PDA alone rather than using it for testing.

Microsoft have now made available emulator images for Windows Mobile 6.1. While these are primarily designed for developers, they will run standalone with the Windows Mobile emulator.

For those of you using Exchange 2007 this release also gives you the opportunity to test out the new policies that were introduced with Exchange 2007 SP1 which bring the functionality of Windows Mobile closer to that of Blackberry , with control over the devices and the features that are enabled. (More information on those polices here: http://blogs.msdn.com/jasonlan/archive/2007/12/04/exchange-activesync-policies-summary.aspx)

Network Support

I tried to get these images to work on my Vista machine, using the now withdrawn network driver. However the network driver would not install on to the machine. Instead I had to download and install Virtual PC on to my machine (something that I was hoping to avoid).
On my Windows XP machine the network driver would install fine and worked well with these images.

Download Links

You need to download both parts, although if you already have the emulator installed then these new images will work with it fine.

Windows Mobile Emulator 3.0:
http://www.microsoft.com/downloads/details.aspx?familyid=A6F6ADAF-12E3-4B2F-A394-356E2C2FB114

Windows Mobile 6.1 Emulator Images Download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=3d6f581e-c093-4b15-ab0c-a2ce5bffdb47

Windows Mobile 6.0 Emulator Images Download:
http://www.microsoft.com/downloads/details.aspx?familyid=38C46AA8-1DD7-426F-A913-4F370A65A582

Last year I wrote about how I was caught out with detecting Vista in login scripts (http://blog.sembee.co.uk/archive/2007/01/06/31.aspx).

Following the release of Service Pack 1 for Windows Vista, I was caught out again as the version number has changed. In my login scripts I use the output of the command "ver" to detect the operating system.

With Windows Vista RTM it was 6.0.6000. With Windows Vista SP1 it is 6.0.6001. Therefore any login scripts that detect Vista need to be updated to include both version types.

This is easily done and should not mean too much additional code.
If you have used the method in my examples and put the script commands in to sections, you simply need to add a line to the detect the later version:

findstr "6000" %systemdrive%\ver.txt
if not errorlevel 1 goto vista
findstr "6001" %systemdrive%\ver.txt
if not errorlevel 1 goto vista

:vista
rem vista commands here

By grouping them together the same commands can be used for both RTM and SP1 versions of Vista, unless you need to use different commands for the different versions.

One of the worst experiences for an Exchange administrator is to come in one morning and find that either email is being blocked, the queues are long or the users are getting NDRs saying that the server is blacklisted.

This seems to result in confusion amongst administrators who then go looking for advice only to get conflicting answers on what the problem might be.
I am going to try and clear up some of that confusion which should help Exchange administrators find the source of the problem.

There are two main issues that Exchange administrators seem to see and fail to understand.

1. There are a large numbers of messages in the queues.
2. The IP address of the server has been blacklisted.

In both of these occasions many administrators seem to think that a client machine on their network has been compromised and is sending email through the Exchange server.

This is not the case.

To abuse an Exchange server in this way, a BOT writer would need to

1. get the BOT inside the network
2. infect the machine
3. realise that it is on a corporate network where there is an Exchange server
4. find the Exchange server
5. send the message.

The above, is not going to happen - at least not at the moment. Too much like hard work. The first two are the most difficult - if the network security has been configured correctly and the users trained to recognise potential suspect emails or web sites.

Then sending the message requires either a MAPI interface or SMTP to be configured on the Exchange server to allow users to relay through the server. While this is default, if you do not have any users who need to relay through the server (Outlook, OWA and Windows Mobile/Blackberry BES users do not need to) then you should disable it.

Then for a successful infection and abuse, the above is also presuming that the user is an administrator and the network admin will not notice the infection!

What the BOT writer is really looking to do is infect clueless home users who are not keeping their machines patched, not using security software and are running as a local admin. Much higher chance of success there involving simpler techniques.

Therefore with the target in mind, the BOT will usually have its own SMTP engine and will be sending out email directly to the internet.

So what has happened?

If you have been blacklisted but the queues are clear, then a client machine has probably been compromised. This is often the case when you have a single IP address on the Internet which is shared among all machines on your LAN.

However to further complicate things - if you are using a smart host - such as your ISPs SMTP server - then your queues could be clear but the server is still being abused. However in that scenario it is likely that your server would not be blacklisted on public lists, but your ISP may have noticed and not be very happy with you. If messages are not being delivered to the smart host then phone your ISP and ask - or they may phone you. Often ISPs will block first and ask questions later.

Finding the Source - Compromised workstation

A quick and dirty method to find the compromised machine is to simply stop Exchange from sending any messages by freezing the outbound traffic, and then block port 25 on the firewall and wait. A compromised machine will quickly show on the logs when it cannot connect. You can then go and find the machine and deal with it.

Having up to date Antivirus is not enough. Once the BOT is on the machine, it is no longer your machine. The only way to ensure that it is clean is to wipe the machine. BOTs are very good at hanging around and they will update themselves regularly.

There is a complication on this as well - if you have been foolish enough to browse from the Exchange server then the server itself may have a BOT and be sending out messages. However those messages would still not show in the queues. If you don't browse from the Exchange server then that shouldn't be the cause of your problems.

Finding the Source - Large Number Of Messages in the Queues

If you have a large number of messages in the queues, then those will be coming from outside your network. That does not mean you are an open relay, there are other ways that the spammer can abuse your server.

The two most common are authenticated relaying and the NDR attack.
I have discussed these in more detail in my spam cleanup article on amset.info - http://www.amset.info/exchange/spam-cleanup.asp .

However in short, authenticated relay is where the spammer has attacked your SMTP port trying to break a password - usually the administrator account. Once broken, the account is used to relay email. Authenticated relaying is enabled by default.

An NDR attack is where messages are sent to your server to non-existent users on purpose. Either as a directory harvest attack (to see what users are valid) or to get your server to bounce the messages to the "sender". The sender is spoofed and is the actual target.
Exchange 2000 is unable to defend itself against these kinds of attack without third party support. Exchange 2003 and higher has features built in to deal with this kind of threat, however if you have Exchange 2003 on Windows 2000 then you should not use them as Windows 2000 is unable to defend itself against a directory harvest.

So what do you do?

When you first notice there is a problem, you need to verify whether it is the result of an attack or compromised machine, or the result of a configuration error or change. Do not presume one or the other.
Once you know which it is then you can look further.

If you are dealing with an ongoing problem then pull the plug on the internet connection. That will stop messages going out and if the spammer is abusing your server will stop the messages from piling up. This will give you some breathing space to clean up and see what is going on.

If your IP address has been blacklisted, then use your ISPs SMTP server to send email through.

Ideally you should have at least two IP addresses so that the Exchange server can have its own address. If a workstation is then abused it does not result in your email IP address getting blacklisted.

Remember, any SMTP server is a target for a spammer. They don't want to use their own resources, they want to use those that belong to someone else so that they can hide.