Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Catch All Mailboxes and the POP3 Connector

I have recently seen an issue with the POP3 connector which I haven't seen before, but will be very widespread. In this particular circumstance it caused the client's server to get blacklisted and have a server processing many thousands of messages which it shouldn't need to.

It is yet another reason why using the POP3 Connector is a bad idea. I have blogged on the POP3 connector being a bad option in the past: http://blog.sembee.co.uk/archive/2006/09/25/25.aspx .

This client was not only using a POP3 connector, but they were also using a catch all mailbox at the ISP - I have posted today why using a catch all is a bad idea here:  http://blog.sembee.co.uk/archive/2010/02/15/117.aspx (posting that item was inspired by this one).

The Problem

The actual problem was quite simple, and something that Exchange could have dealt with on its own if the server was setup for SMTP delivery. However it became a noticeable issue because of the way this particular server was configured.

The domain was subject to an NDR or directory harvest attack (I cannot tell which due to the nature of the SBS Connector) and ended up with large numbers of email messages in their queues.

What puzzled the client was that port 25 wasn't open to the internet, and they had followed my guides on recipient filtering and authenticated user relay so that the server was secure ( http://www.amset.info/exchange/spam-cleanup.asp ).
As I wrote in that article, messages can continue to appear in the queues for some hours after the initial clean-up due to the way Exchange displays the queues when there are a very large number of messages in the queues. However for this client, the messages continued to appear for weeks. Eventually, fed up with cleaning the queues daily, I was asked to look at the server.

What I found was that the messages in the queues were all from postmaster@ so had the classic hallmarks of an NDR or direct harvest attack, but the client was using the POP3 Connector.

Due to the way the POP3 connector works, messages that come in to the server through it are not subject to the recipient filter. The recipient filter works at the connection point, but the POP3 connector simply drops the in to the queue for delivery. This is the key point and the result was the same as a standard NDR attack through SMTP without recipient validation  - the messages that could be delivered were, and the messages with invalid external recipients, or where there was a delivery problem, hung around in the queues. As time went on, the server became blacklisted by most major ISPs for being a source of spam and back scatter.

Furthermore, the client also had the POP3 connector setup to send a copy of messages that could not be delivered to a valid user  in to a mailbox, so not only were the messages being delivered there (and the client had what they considered to be a major spam problem) but the NDRs were going out as well. The user concerned thought they were receiving large amounts of spam - when in actual fact they were receiving email that wasn't even addressed to them.

In short, it was a complete mess.

This will be a widespread problem

In many respects, the client was not to blame for this problem. This configuration is quite common, and would therefore affect everyone using the POP3 connector with a catch all mailbox. However you may not see the messages in the queues and therefore be unaware that your server is a source of spam or backscatter.

The most common configuration when SBS is used with a POP3 connector is to route email OUT through a smart host - usually the ISPs SMTP Server. If you are doing that in combination with a catch all mailbox then you wouldn't see the symptoms of this problem. When a smart host is used, Exchange is sending the email straight back out again and the smart host is responsible for the delivery of the email.

It was only because this client was using direct delivery rather than a smart host that the email messages were shown in the queue causing further investigation. The client had accepted large amounts of spam in the mailbox as something that happens - and asked me to look at that as another issue - not realising that it was all caused by the same thing.

If the server had been configured in the usual way for POP3 use, that is to use a smart host, then the first the client would have known there is a problem is when their ISP called to tell them - although many do not.

Furthermore the email messages also do not appear in message tracking logs as they do not pass through Exchange, but simply bounce off SMTP. The only messages that do appear in message tracking are those delivered to the user set to receive the messages that could not be delivered.
Therefore a server could be the source of back scatter and the administrators (whether in house or an external support company) would be completely oblivious to the issue.

I haven't been able to verify if the email messages showed in the volume reported by the SBS Reporting tool, because as with most SBS Servers I see, it wasn't turned on.

The Solution

Changing the client to SMTP delivery of email resulted in the spam level dropping immediately. In the 24 hours after the change, the number of messages the server dropped for non-valid recipients was measured in 1000s. The account which received a copy of the unmatched addresses from the POP3 connector saw the level of spam almost completely drop away - as most of the spam wasn't addressed to the user.

Conclusion

There is a very simple conclusion to this blog posting.
Don't use a catch all mailbox with the POP3 Connector. Ideally you shouldn't use the POP3 connector at all.

If you are using the POP3 connector and do not wish to move to SMTP delivery, then you should look at switching to user specific POP3 mailboxes instead of a catch all. While that is more tedious to setup, it does mean you are only downloading email that you may want, rather than lots of spam that you almost certainly do not, only for it to be rejected.

Why you shouldn't use "catch all" mailboxes

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.
In this post I am going to outline why a "catch all" mailbox is a bad idea.
Many of the points in this article also apply to enabling the option to have a copy of any Non Delivery Reports delivered to someone else in the Exchange org.
This post applies to all email servers, not just Exchange though.

I actually completed this post some time ago, I just never got round to putting it on the blog. However I have recently seen a problem with a SBS Server where a catch all mailbox was used, which I am going to blog on separately, so thought this article should go up first.

The other articles in this series to date are:

Why you shouldn't use logos in signatures ( http://blog.sembee.co.uk/archive/2008/04/14/76.aspx )
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 )


Where does the request come from?

Newcomers to Exchange will often ask where is the "catch all" option, particularly if they are used to that option provided by their ISP with POP3 mailboxes, or are coming from the POP3 connector on Small Business Server.
It may also be asked by a manager, in the mistaken belief that they are missing out on important emails when someone mistypes the email address.

Of course Exchange doesn't support catch all mailboxes, which is why the question is asked.

Similarly, I have seen servers with the "Send copy of Non Delivery Report to..." option set on the SMTP virtual server so that someone gets a copy of the message which can be forwarded on to the relevant person. Of course that is just a COPY, the sender will already have received the NDR, and then may get confused when their message is replied to, despite getting an NDR saying it wasn't delivered.

Why are they a bad idea?

Catch all mailboxes have been a bad idea since the late 1990s, with the growth of worms on the internet that make up email addresses.
In short, a catch all mailbox means that every email address on your server is valid. Therefore the bots that create email addresses based on common name combinations will be able to successfully deliver their messages to your server.

As such, if you enable a catch all, then someone needs to monitor the mailbox constantly for the odd valid email message. Depending on the number of users, the number of messages that could by saved by the catch all may be one or two a day at most.

Meanwhile the person monitoring the mailbox will be deleting the vast majority of the messages, as they will be spam and virus infected messages.
The fact that messages have been delivered at all is also a security risk. If the message is opened or the attachment looked at because it seems legitimate, then the payload could be executed. However if the message had been dropped then it would not even get the chance.

By dropping messages to invalid recipients you will save on bandwidth as the messages do not have to be delivered and on processing power, as the messages do not have to be processed by your AV, Antispam and then Exchange.

Furthermore, if a spammer decides to launch an NDR attack, or simply sends a large amount of spam to your domain, then the messages will be delivered. You may find that you have a mailbox that Outlook cannot open because it has 150,000 messages in it.

I have posted on this blog in the past about VAMSOFT ORF which uses emails to non-valid addresses as a feature to block spam, to great effect. If you are receiving 10,000 messages a day to non-valid address then that would be a tremendous waste of bandwidth - I have a client who drops this kind of level a day.

What is the problem with "Send copy of Non Delivery Report to..." option?

With the "Send copy of Non Delivery Report" option, if you have that set, you are actually being a poor internet citizen. To receive a copy of the Non Delivery Report (NDR) you need to allow the message to be delivered. The server then attempts to send the original NDR back to the sender. However if the message is a virus or spam message (which is most likely) then the sender will be spoofed. Your server is then a source of "back scatter" which could lead to a poor spam score or even blacklisting.
During the last major email-borne virus attack, there were more back scatter NDRs going back and forth than infected messages.
 
Your server is also exposed to an NDR attack or NDR spam attempt, as the server will accept the message and then try and send it back to the "sender" who is the real target of the message.
I have more on NDR attacks on my spam clean up page: http://www.amset.info/exchange/spam-cleanup.asp

Then there is the internal security aspect. If someone senior makes a typo in a confidential email address, this could be seen by someone else, who possibly should not. The original sender will be unaware of this, because they will still get a copy of the NDR.

What are the alternatives?

If you have Exchange 2003 or higher on Windows 2003 SP1 or higher, then enable the recipient filter and tar pit option (instructions: http://www.amset.info/exchange/filter-unknown.asp ). Anyone who sends an email to the wrong address will get a failure immediately. If they are a legitimate sender then they will call or email someone else to get the correct email address.
On older versions of Exchange or if you can't set the tar pit, for example when Exchange 2003 is installed on Windows 2000 where the option isn't available, then setting recipient filtering can actually expose your server to attack, as it cannot defend itself from a directory harvest - therefore a third party tool is required such as Vamsoft's ORF to do recipient filtering and the tar pit.
For other email server products, you should check for recipient validation functionality. If it doesn't exist, but an LDAP lookup option is available, then something like VAMSOFT ORF can query an LDAP database for valid addresses, so could be used as an SMTP gateway. ( http://www.amset.info/exchange/gateway.asp )

If you are aware of a common misspelling, for example Steven and Stephen, then add the misspelling to the user's account as an additional email address. That will ensure that the common misspellings are delivered, without exposing your server.

Blackberry Server 4.1.x and Exchange 2010 - Working

With the release of official support for Exchange 2010 and BES 5.0, I thought I would have another crack at getting Exchange 2010 to work directly with BES 4.1. This is instead of using an Exchange 2007 server somewhere in the mix.

I used Blackberry Professional Server in my testing, installed on Windows 2003 separate to Exchange 2010.

To my surprise, I have managed to get it working - with no interim servers used. A clean Exchange 2010 installation was used, along with BPS 4.1.3A (so not even the latest version).

In addition to the regular installation of the Blackberry Server software (so logged in to the machine as besadmin etc), to get things to work I had to do the following.

  1. Install Exchange 2010 rollup 1 on the Exchange server.
  2. Install the latest version of the CDO on the Blackberry server.
  3. Set more permissions than normal (see below)

The server I was using also had a public folder store created and mounted. I have not tested it with Exchange 2010 without Public Folders.
During the installation there was an error about being unable to verify the permissions, which I ignored.
 
Tested Functionality

I have tested the following:

  • Full over the air Enterprise activation. 
  • Sending and receiving email from the device. 
  • Lookup against the GAL and the personal address book
  • Adding a task from the Blackberry and seeing sync to the account. 
  • Adding a task from OWA and seeing it sync to the Blackberry
  • Adding a calendar entry from the Blackberry and seeing sync to account.
  • Adding a calendar entry from OWA seeing it sync to the Blackberry

Of course functionality that doesn't require Exchange - such as Blackberry Browser access to the intranet continues to work correctly.
 
Permissions

To get things to work, I had to set additional permissions. This may well be related to the change in the database model, which is now at the Org level rather than the server level.

Exchange 2010 View Only Exchange Admin.

This permission is no more, so the equivalent has to be set:

Add-RoleGroupMember "View-Only Organization Management" -member besadmin

Store  / Server level permissions

The usual permissions used with Exchange 2007 set via the following command didn't appear to work:

get-mailboxserver | add-adpermission –user BESAdmin –accessrights ExtendedRight –extendedrights Send-As, Receive-As, ms-Exch-Store-Admin

I had to grant the permissions at the database level:

Get-MailboxDatabase |add-adpermission -user besadmin -accessrights ExtendedRight -extendedrights Receive-As, Send-As, ms-exch-store-admin

Get-PublicFolderDatabase |add-adpermission -user besadmin -accessrights ExtendedRight -extendedrights Receive-As, Send-As, ms-exch-store-admin

As the permission is being granted at the mailbox database level, if databases are changed/added/removed then the permission will need to be run again.
As always, the permission didn't take effect immediately, therefore I restarted the information store and the Blackberry services to get things to take effect.

CDO Installation

The latest version of CDO was used, which can be downloaded (At the time of writing) from this location:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en

Exchange 2007 SP2 Install tool for SBS 2008 Released

At last Microsoft have released the installation tool for Exchange 2007 SP2 on SBS 2008.
Looks fairly straight forward to use, download the service pack as normal, download the tool and then run the tool.

You can get more information about the tool and download it from this KB article:  http://support.microsoft.com/?kbid=974271

Exchange 2007 has been rock solid in my experience and if you were put off installing it on your SBS 2008 machine because this tool wasn't released, now is your chance.

exbpa.com saved for the Exchange Community

I am pleased to announce that the domain exbpa.com has been saved for the Exchange community.
This was a domain that Microsoft first used a few years ago to point to their (at the time) recently released Exchange Best Practises Analyser. There are thousands of links to this domain across the internet as well as in books and magazines.

However Microsoft recently decided to allow the domain to lapse and early this morning it was finally deleted.

Fortunately I was able to register it myself through my consultancy company Sembee Ltd and therefore kept it out of the hands of a domain squatter. 

I have uploaded a slightly modified version of the list of Exchange resources that I maintain at Daniel Petri's forum, which as well as the links to the Exchange Best Practises Analyzer, also contains links to other Microsoft tools, blogs etc.

http://exbpa.com/

While it is not the best designed web site in the world, it does the job. Hopefully the Exchange community will find it of some use.