Sembee Blog of Exchange MVP Simon Butler

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.

This is another post in my series of articles on why you shouldn't use certain features in Exchange, even though they are there - although in this post is about an Outlook feature - PST files.  

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)

In this post I am going to outline why you shouldn't use PST files.

Anyone who has worked with Exchange or Outlook for more than 10 minutes will know about PST files. However despite their numerous flaws, they continue to be in widespread use. Where possible you should ban their use, particularly for archiving purposes.

The main arguments against using PST files are:

Data Loss When They Get Too Large

With Outlook 2002 and older, PST files can go to a maximum of 2gb, but in an annoying flaw, the file will allow you to continue to add data past the 2gb limit. You only get problems when you try to open the file again. Microsoft do have a tool that will allow you to open a file that has gone over the limit, but it simply chops off all data over 2gb - therefore resulting in data loss.

With Outlook 2003 and higher a new format of PST file is used (which is not backwards compatible) which allows PST files to go to 20gb. You cannot convert the old version to the new one. If you have create the wrong type then you will need to create it again and move the content across.

PST files are very fragile things, particularly the larger they get. Many people will suggest a new PST file at 1gb or less to protect the data.

Backup of the Files is Awkward

Microsoft do not support accessing PST files over a network. (http://support.microsoft.com/default.aspx?kbid=297019 and
http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx ).

That basically means they are impossible to backup. You cannot store them locally and backup over a network, and you cannot store them on a network share and access them over the network. Considering how fragile they are this is asking for problems.

Single Point of Failure / Risk of Corruption without Knowing

It is perfectly possible to have a corrupt PST file and not know about it for weeks or months. It is perfectly possible to continue to access and have open a PST file and not know that some of the data has become inaccessible.
Furthermore due to the fact that they are not supported being accessed over a network, that means keeping copies of them is not really practical. You cannot store them in "Read Only" format or access directly from a CD as the file will not open. Outlook needs write access to open the file. That would mean copying the file off the read only source, changing the tag on the file and then opening it. That could cause corruption in the file.

File Bloat

Due to the way that PST files store their data, they will actually use more space than the same data in Exchange - up to three times, and that is not taking in to account the loss of single instance storage.
100mb of email can be as much as 300mb in a PST file.
If ten users were sent a 2mb file in Exchange, then it uses 2mb of space in the store. Extract to PST files that same file would use up to 60mb as each user has their own copy in three different formats.

PST Files are not an Archiving Solution

The above should be enough to know that they are not an archiving solution. If you value your data do not store it in a PST file.
If you need to keep content for regulatory reasons, then a PST file will fail on many counts, such as allowing the user to modify the item after it has been received.

Are there any reasons to use PST Files?

If you aren't connected to Exchange, then you have no option but to use PST files.

With migrations, in some scenarios they are the only option, because they are domain independent. A PST file from one domain can have its contents imported in to another domain. However the same issues with the files remain, so when using them for this type of migration caution must be taken to ensure the data remains intact. 

Conclusion

Hopefully the above will give you some idea why PST files should not be used where there is any value to the data.

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.

This is another post in my series 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 are:

- why you shouldn't use the POP3 connector: http://blog.sembee.co.uk/archive/2006/09/25/28.aspx
- home grown versus commercial SSL certificates: http://blog.sembee.co.uk/archive/2006/03/05/9.aspx

For this article I am going to outline some of the reasons why you shouldn't enable the POP3 server on the Exchange server. This is different from the POP3 connector, which is used by Small Business Server to pull in email from an ISP. This is POP3 used to collect email from Exchange.

Why is POP3 enabled?

POP3 is not enabled by default and there are a number of reasons why it is enabled.

Some administrators enable it because that is all they know, and they want to use Outlook Express for email. This is familiar to them and their users.
Others enable it for remote access, because either they don't know about or cannot use RPC over HTTPS (aka Outlook Anywhere (Exchange 2007) or Outlook over the Internet (SBS)) http://www.amset.info/exchange/rpc-http.asp

It may also be enabled to allow other non Microsoft clients to access email.

However in most cases it is a request from a user, who may or may not be completely up front about why they want to use POP3. POP3 can be used/abused in so many ways that it is one of the reasons why the Exchange server admin should really think twice before enabling it.

Therefore the first thing an Exchange Server admin should do when they are asked to enable the feature is ask the question why. If the asker then goes coy, you know it may not be in the business' best interest to enable it.

Why Shouldn't You Enable the POP3 Server

There are any number of reasons why the POP3 server should not be enabled. These are the most common reasons why not:

1. Username and Password Sent in the Clear.
   In the default configuration, POP3 sends the username and password across in the clear. That is a security risk. If you really do need to enable it, look at using SSL to secure it. 
2. Risk of content loss.
   POP3 is designed to REMOVE the content from the server and store it locally. It is too easy for a user to download the content and remove it from their mailbox. While there is a setting to leave the email on the server, it cannot be controlled server side, so you are reliant on the user setting the client in the correct way.
   As the data is being stored locally, it cannot be backed up easily, therefore if the user loses their machine, it is stolen or suffers a hardware failure, then the email is lost as well.
   I have also seen it abused, as a way to get content out of the network - sales people in particular want the feature so they can store a copy of everything at home. A significant number of sales people are not loyal to their employer at all, and would prefer that their clients do everything through them, ideally on a personal email address.
3. Loss of control of access.
   Once POP3 is enabled, it can be used by any number of things, PDAs, phones, Blackberry etc. The IT department may or may not know about those, and be unaware of them in the event that they cause a problem. 
4. Storage and Regulatory Compliance Concerns.
   If you operate in an environment where you have to store email or be aware of the content of the messages, then that is a big argument not to enable POP3.
   If the client is configured for POP3 and email is sent from that client, then there is no way it can get back in the store unless it is imported. If the user is sending email with something obscure, then that isn't going to happen.
   The user could also be sending email out through another SMTP server, even sending email with their personal email address as the reply to address (again sales type people are notorious for doing this - then claiming it was an "accident").
5. Feature Loss
   You also lose the GAL, calendaring and everything else that Exchange offers. If the email is being extracted then OWA becomes close to useless, no sync to Windows Mobile devices over the air.

If your must enable the POP3 Server

As with many things in the Microsoft world, everything is enabled until you turn it off. POP3 access is no exception. If you enable the server then all users will be able to use POP3. Even if you don't publish the information about how to configure it, if OWA is used and the port is open, the users will soon work it out - the information is all over the internet.

Therefore if you must enable it then you should secure it.

1. Use admodify.net to disable the feature in bulk for Exchange 2003 users, Exchange Management Shell for Exchange 2007 users. Then enable it for the users who need it only.
2. Use SSL and only open the POP3S port (995). That will slow down a causal user.
3. If you can, use IMAP instead. That leaves the content on the server. It isn't perfect as there is still the chance that email is sent out via another SMTP server, but it is better than POP3.

Conclusion

Make sure that management are aware that it is being enabled and are aware of the risks that are involved. If they say no (which is ideal) then you can simply turn down future requests with that same message.

My personal opinion is that POP3 has no place in a corporate email environment and there is no need to enable it at all.
If you need to provide access to mobile devices, then purchase suitable devices that use either Windows Mobile or Blackberry.
If you need to provide access to non-Microsoft clients, use IMAP.
If you need to provide remote access for Outlook, then use RPC over HTTPS.

There are so many reasons why you shouldn't use a POP3 connector on an Exchange server that it is difficult to know where to start.
I don't simply mean the POP3 Connector supplied with Small Business Server, but any third party POP3 Connector. They all have the same issues.

With the correct choice of services and configuration, there is almost no reason why a POP3 connector should be used as part of the deployment of Exchange.

POP3 is a client to server protocol. Designed for pulling email from the server for storage in the client. Exchange is not a POP3 client. All that the POP3 connector does is pull the email down, then place it in to the SMTP queue for delivery to the end users.

With the SBS POP3 Connector, that is done at 15 minute intervals.

I have outlined the most common arguments for using the POP3 connector below and why they don't make a very good case.
Then I have outlined the major benefits of using SMTP delivery.

I may well update this article in the future, so if you are using the RSS feed and it comes up again, then that is why.

Common Arguments for using the POP3 Connector.

I don't have a static IP address.

Not having a static IP address is not a hurdle for hosting your own email.
Simply use one of the dynamic DNS services to map a dynamic DNS to your MX record host, or just use the dynamic DNS address host in your MX records.
You will need to put a tool on to the server to keep the dynamic DNS address active, but there are lots around.
http://www.amset.info/exchange/dynamicip.asp

My ISP blocks port 25.

If you are running Exchange on a "residential" connection, or the ISP wants you to upgrade to a business class connection that costs many times the normal amount for basically the same service, then you may find that port 25 is blocked.
For outbound email you can use an SMTP Connector.
For inbound email, simply subscribe to one of the mail hop services. These services provide you with hosts that you put in to your MX records and will receive email for you. They then forward the email to you on an alternative port that is not being blocked.
Furthermore, in the event of a failure of your server or internet connection, these services will queue the email for you, which also deals with the "protection" reason (see below).

It provides "protection" in case the server goes down.

One of the most common reasons that people want to use the POP3 connector is because of the protection that is provides for them in case the server goes down.
This is often the reason given by people who don't understand the way that email and SMTP delivery works on the internet.

You should have complete control over your email at all times.
In fact, you should have control over all aspects of your internet service.

What happens if your ISP goes bust? It happens. Not as often as it once did, but it does happen.
If you are using a dedicated web hosting company, then they are more likely to go bust than regular ISPs, because the hosting market is so competitive. (I can rent a dedicated server for UK£45 a month - on that I could get 100 web sites very easily).

You have an disagreement over a bill with your ISP. They cut off access to your email until you pay the bill - holding you to ransom. 

You should have the email delivered to your server at all times, using SMTP. That is what Exchange is designed to do.

However, many people will see that the Exchange server is a single point of failure for email delivery. Unless you pay out for additional services and applications, that will be a factor for most companies.
You also have the internet connection - that is often a single point of failure as well.

SMTP email has some protection built in. Most servers are configured to attempt to deliver email for 48 hours before giving up. If email is that critical to your business, then you will not wait 48 hours before getting some kind of email service. Where hardware is available, I can have a server back running in around four to six hours. It may not have the old information available to the users, but what most companies want is new email, the old content can wait a bit longer.

If hardware isn't available, then you can use an alternative email service, collect the email with POP3 and then import it back in to Outlook. That can be fixed up in around 30 minutes, with just clients to configure.

If you are in a larger site with multiple servers, then it probably doesn't apply as you will be able to make internal arrangements.

My mention of POP3 in the previous paragraphs doesn't mean using the ISPs POP3 service, or supports the use of the POP3 connector.

How can you protect yourself?

The biggest problem with making alternative arrangements is the DNS propagation time. It takes 48 hours for DNS changes to fully propagate round the Internet. Therefore if you were to rely on replacement DNS changes, you would loose email.

The trick that I like to use is to use a second MX record and a dynamic DNS service provider.
The dynamic DNS entry is pointed at your existing IP address - so you have two MX records pointing at the same location:

MX value: 10 mail.domain.com
MX value: 50 companyname.dyndns.org

mail.domain.com Type: A Value: 123.123.123.123
companyname.dyndns.org Type A: Value 123.123.123.123

Note that two hosts have been used, not a alias to the original host.
While this does break the official best practises for MX records in having two records pointing at the same host (which will be flagged if you use dnsreport.com for example), in operation it has no effect.

In the event of a failure, the original lowest value MX record is no longer responding. The sending servers will try the higher value MX record - which at the point of failure also isn't responding.

Simply change the IP ADDRESS on the dynamic DNS record to point to your alternative server or internet connection. No other changes are required, and email will begin to flow very shortly afterwards.
You haven't got to wait for DNS changes to propagate, because they are already there. The dynamic DNS services have setup their service so that host changes are reflected around the internet very quickly.

Once the original server has been fixed, change the entry back again and email to the alternative server or IP address will very quickly dry up.

Why not use a Backup MX Service?

You may have seen advertised backup MX services. This is where another server is configured in your MX records to accept email for your domain - using similar values to my example above.

The reason not to use backup MX services is quite simple.
In most cases it is only spammers who will use the second (higher value) MX record to send email. The theory being that the backup record is not so heavily protected against spam.

One of the most effective ways to deal with bandwidth use by spam and virus carrying messages is to simply refuse delivery for users who are unknown on your server. http://www.amset.info/exchange/filter-unknown.asp
This feature works by rejecting the message at the SMTP stage, before the message has been delivered. In a small site it is very effective.

If you are using a backup MX server, then you will probably be unable to use that feature, because the backup server has already accepted the message. Attempting to refuse delivery of the message will cause the messages to queue on the ISPs server as they are trying to bounce the message back to the "sender". In most cases the sender of the spam is spoofed and doesn't exist.

My ISP / Web Host doesn't provide an SMTP feed.
That excuse is one that is regularly heard. You don't need an SMTP feed to host your own email. That excuse often comes from the ISP / host, who just want control over everything. They recognise that you could be using your own email server, and want to ensure that you have a level of reliance on their service. They may even be charging you on a per mailbox basis, and don't want to see their revenue stream removed.

To have email delivered to your email server, all you need to do is get your MX records configured to point at your server instead of theirs. If they will not change the MX records, then transfer the domain to a domain name registrar where you have complete control. You can continue to use the ISP/host for hosting the web site (despite what they may say).

I have users who need to collect email from outside by POP3.
If you have any kind of permanent connection to the Internet, then they should be collecting email from the Exchange server. Configuring a domain and Exchange server to share a domain with another email server is problematic and an administrative overhead you could probably do without. It can be done, and is documented on the MS KB but I wouldn't advise it.

If you are on Windows 2003/Exchange 2003 or SBS 2003 then remote users should be configured to use RPC over HTTPS. This gives the user the Exchange feature set, without requiring a VPN. It just needs an Internet connection.

I don't have a permanent internet connection.
Of the main reasons for using a POP3 connector, this one is probably the only reason for using it for some sites. It is probably the ONLY reason I would deploy the POP3 connector, and that would be only after all other alternatives have been investigated an found not to be available.
However you still don't have to use the POP3 connector.
Use an ISP that supports ETRN collection. This is effectively "SMTP on Demand". The Exchange server connects to the Internet and then sends the ETRN server a command to say that it is ready to receive email, and the ETRN server then delivers it. You get most of the benefits of the SMTP type delivery, but without the hassles of POP3 collection.

The CEO wants to import his personal email in to his Exchange mailbox.
This reason has started to become more frequent with the increasing amount of space available in web mail services. There is no technical reason why this is a bad idea. Depending on the relationship you have with the staff member who requests it, you may not have any other choice.

However the best counter-argument for this reason is the loss of privacy. It is personal email. Once it has been imported in to Exchange, it becomes business content. It will be backed up and could be read by anyone else once the staff member has left the company.

Does that email have a place going through company systems?

I am also very suspicious of someone using personal email for business purposes. Why would they want to mix personal and business email up. The main reason is so that they can remain in touch once the business email is no longer available. Or perhaps they don't trust business email or are hiding something.

Benefits of SMTP Email Delivery

If you are currently on a POP3 connector, then why should you switch to SMTP delivery?

It is How Exchange is designed to work.
Exchange was built around the SMTP protocol, and is designed to work with SMTP.

Almost Instant Email Delivery
Most POP3 connectors will only collect email at most every minute, and the SBS POP3 Connector at 15 minute intervals.

As a consultant, one of the easiest ways for me to look good is to ditch the POP3 connector and switch the client to SMTP. The users see an immediate benefit as email is delivered shortly after it is sent - not when the server decides to collect it.

Add and Remove Users easily
You can simply add and remove users, email accounts, distribution lists to the server without having to worry about the configuration of the POP3 account. If you have named mailboxes with the ISP, then you don't need to configure those either.
If you are using a "Catch All" type mailbox, then you have bigger problems which can be solved by using SMTP delivery

The most effective anti spam measures are based on SMTP delivery
If you want to effectively deal with spam, then you need to block it at the point of delivery. With a POP3 connector you cannot do that, as it has already been "delivered" - to your ISPs server. If you attempt to block the message after that point your ISP will probably make you stop and insist that you download all the email that is waiting for you.

If you are using a "catch all" email account, which POP3 connectors, do, you will be bringing down spam messages with your legitimate email. As the sender of the spam messages is more often than not spoofed, your server will be unable to bounce the message and the messages will either queue or have to be dropped. This is a waste of bandwidth.

The two most effective methods of dealing with the major of spam messages are filtering unknown users (http://www.amset.info/exchange/filter-unknown.asp) and grey listing (http://blog.sembee.co.uk/archive/2006/09/18/27.aspx) .
Both of those require the email to be delivered directly so that the messages can be blocked.
Those measures are also effective against many of the email virus threats.

Remote Sites Know the Message Has Been Delivered
When you have your email delivered directly, remote sites can check their logs to see that the message has been correctly delivered to your server.

A constant theme on many of the Internet forums is the use of self generated SSL certificates versus purchased SSL certificates, particularly when deploying RPC over HTTPS or Outlook Web Access.
Many people will advocate that using a self generated certificate is fine and will do the job.
This could be a certificate generated from the selfssl.exe tool that is supplied with the IIS Resource Kit, or Microsoft's certificate application.
However I am not one of them, and always deploy Exchange with a purchased certificate.

Use of SSL Certificates
SSL Certificates have two main tasks. 

1. To prove that the server you are accessing is the server that you meant to access.
2. To encrypt the connection between the application being used to access the server, and the server itself.

There are three things that your web browser looks for when accessing a secure site.

• that the name on the certificate matches the address being accessed
• the certificate is issued by someone the browser trusts, or the certificate matches one already installed on the web browser
• the certificate is valid.

If any of those three fail, then you will get a warning message popup.
With self generated certificates, you will get the warning message when you access the server. This is because the certificate hasn't been issued by a trusted authority.
You can get round that warning message by importing the certificate in to the web browser. However that makes a lot of work with deployment, complicates matters and also means that you have to repeat the exercise when the certificates expires.
It also doesn't help when people are accessing your site from a public computer where you cannot install the certificate, such as an internet café or their machine at home.
And that is where self generated certificates start to cause problems.
You can tell your users to ignore the message when connecting to your site, but users have a habit of only hearing what they want to hear. They will hear "ignore the message" but forget the bit "when using our site". In these days of phishing and spoof web sites network administrators need to give out a consistent message - and telling users to ignore a security warning is a very example of failing to do that.
A security warning of any kind looks unprofessional and shows a lack of concern for security.

So what are the alternatives?
The best alternative is to purchase an SSL certificate.
However many administrators think that they need to go to one of the big SSL certificate issuers such as Verisign and pay US$400 or more per year - and that is just for a 40 bit certificate.
That is not the case.
I do my deployments using RapidSSL certificates. They cost US$69 per year and that is for a 128bit certificate. Their root certificate is in most of the popular web browsers so there is no complication there.
If you do need to deploy the certificates to Pocket PC devices, then that can be easily done (see http://www.amset.info/pocketpc/certificates.asp).
You could also certificates from Certificates for Exchange which are trusted by Windows Mobile 5.0 with MSFP and higher. Nothing to install on the devices making deployment easy.
You may also see some "free" SSL certificates around. These should be looked at carefully, paying particular attention to the root certificate support. If the root certificate isn't in the majority of web browsers then you will have the same problem as when issuing your own certificates - prompts and imports.

Do Self Generated Certificates Have a Place?
Yes they do. I use them all the time in lab environments. When I have control over every item accessing the service, then I will use the a self generated certificate and make all of adjustments as required to get it to work correctly. However in a production deployment, they are never used.

If you are looking for a page on how to put Exchange in to a DMZ, then you have come to the wrong place. This isn't it. 
Also I am not posting about deploying Exchange in a secure way - at least not in this post. It just covers Exchange in a DMZ.

I don't deploy Exchange in to a DMZ, never have done, never will do. I discourage anyone who asks about it from doing so.

Yet Exchange in a DMZ is one of the most hotly debated subjects in the Exchange community.
The main "reason" that people want to put an Exchange server in to the DMZ is in the belief that it will increase the security of their network.

However ask yourself this - how does it increase your security? What does putting a member of your production domain in to the DMZ do to increase the security of your production network?

Answer those question with valid reasons, then go ahead and configure Exchange that way. As yet, no one can give me a valid answer to those questions.
Lets look at the reasons why it is a bad idea.

Exchange has to be installed on a domain member. It cannot be installed on a workgroup machine.
Therefore for a member of the domain to work correctly it needs to contact the domain controllers. This means opening ports on your firewall to allow that traffic through.
Furthermore, the Exchange server will talk to any of your domain controllers, and it is good practise not to limit the domain member to talking to just one domain controller. However as you have to allow certain ports through, you will need to change the rules on the firewall to allow the DMZ to talk to a range of IP addresses - even if you subnet it down.

Disabling of Dynamic Ports
Exchange does a lot of communications through dynamic ports. These ports are constantly changing. However to go through a firewall you need to stop it from doing that so that you can open certain ports. That means static ports - which actually reduces the security of your Exchange environment overall.
The change in the port allocation has to be made to all of your Exchange servers - because the front-end machine in the DMZ could talk to any of them. Plus the port has to be opened to all of those servers - making the rules very complex.

Front-end server gets compromised and the attacker walks straight in
As you have changed to static ports and opened the firewall to the the domain controllers, once the machine in the DMZ has been compromised the attacker can walk straight in to your domain controllers. The don't even have to go looking for them. In fact, if they get on to the Exchange server, then they are in already. Exchange will install a copy of Active Directory Users and Computers which the attacker can use to change the password of the administrator account and then has full access.

A Traditional DMZ should be somewhere where you place machines and resources that are expendable
A DMZ exposes machines to the Internet. It is supposed to be a buffer between the production network and the internet. With a domain member in there, it is simply an extension of your production network.
You should be prepared to remove a machine that is in the DMZ with a moments notice. With a domain member and/or an Exchange server you cannot do that. While you can remove an Exchange server instantly, it leaves a mess behind that can take a while to clean up.

A good firewall administrator wants the least number of ports open to the production network.
Having worked with financial institutions, showing them the list of ports that need to be open between an Exchange server on production and one in the DMZ usually means they give up on the idea.
This is the list of ports that need to be open between the frontend server and the production domain to allow all features of Exchange to work. The actual list required can vary from site to site, depending on the features deployed. 

• SMTP: 25 
• LDAP (DC lookup): 389 
• LDAP (GC lookup): 3268 
• NetBIOS (ports): 135, 139, 1024+ (default config is usually 6000 something). 
• DNS: 53 
• RPC: 111, 135, 1024+ 
• Netlogon: 445 
• Kerberos: 88 
• OWA: 80 (HTTP), 443 (HTTPS) 
• IMAP4: 143, 993 (with SSL) SSL   
• POP3:110 995 (with SSL)

The NETBIOS ports (125, 139 etc and 445) are the ones that usually scare the firewall administrators the most as those are frequent targets and the NETBIOS traffic shouldn't be passing over a firewall.
Put all domain members inside the production network and open only the ports that you need to. In many cases this can be two - 25 (SMTP) and 443 (HTTPS).

My company has a policy of no machines on the internal network having direct connection to the Internet.
Valid point and a policy that is to be applauded. However this doesn't make a good reason to put Exchange in the DMZ.
Instead, put an ISA Server in the DMZ, on a machine that is part of a workgroup and publish what you need to through that. Once the machine has been completed, clone it so that if the machine gets compromised you can take down the original, restore the clone, fix the security hole and redeploy (after taking a fresh image). As it is a workgroup machine, there will be no problems with domain membership.

Update 7th March 2006: msexchange.org have just published an article on using ISA and Exchange:
Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 1)

Microsoft have supplied instructions on how to deploy Exchange in a DMZ.
Not really a valid argument. You could probably ask a car manufacturer to give you instructions on how to drive a car off a cliff. They can provide them to - but whether it is a good idea or not is down to you.

Hopefully this posting has given you an idea on why putting Exchange in to a DMZ is a bad idea, and will help you make your own decision when deploying Exchange in a secure way.