I keep coming up against this, and I keep forgetting it, so I figured I'd write it down here for all of our benefit.

Exchange 2003 allowed us to easily mail enable public folders, so something sent to info@domain.invalid would go to a public folder where any number of staff could monitor the mailbox.

However, by default, the mail is stored in the Public Folder as a NOTE and not an E-MAIL (for the geeks in the audience IPM.POST vs. IPM.NOTE)

To make the public folder store incoming mail as emails, we need to make a quick registry change. This is all outlined in MS KB 817809.

Go to

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<GUID>

And create (or edit) the key:

Value name: Incoming defaults to IPM.Note
Value type: DWORD
Value data: 1

Setting the value to 1 (true) stores things as IPM.NOTE (which is what we want). Setting the value to 0 sets it back to saving things as a post.

Talking about SMTP Connectors in an earlier post got me to thinking of another way we use the SMTP Connectors in Exchange.

A client has a (horribly behaved) legacy piece of software that, when faced with a customer with no email address on file, sends an email to an address it makes up in a legitimate domain. So, for a long time, they were bombarding this innocent third party domain with mail that was destined to go nowhere.

This was eating bandwidth, processing cycles and the like, so we tried to put an end to it by appealing to the developers. They were not interested in fixing the old program, it would continue to spit out its bogus mail.

We created an SMTP Connector in Exchange to handle delivery to the legitimate domain. (It should be noted that the domain probably wasn't legit when the program was written, but with the .com explosion, it became legit. It's also not a domain anyone would be sending mail to in the normal course of business... it's not like this is for AOL.COM or anything...)

We set the connector so in the "address space" we listed our desired domain. We checked off "Forward all mail thru this connector to the following smart hosts"

... and this is where we get tricky ...

... we put a non-routable IP address in the smart host field. (And remember to enclose the IP address in brackets - i.e., [10.99.99.88] )

On the Delivery Options tab, when it asks when it should deliver, we tell it to "Never Run"

And that does the trick. We no longer pester the legit domain, we don't eat any bandwidth, everyone's happy.

A client is constantly getting hit with email attacks, and one such attack flooded the Exchange box with a couple hundred bogus NDRs which were trying to be delivered.

Removing these queues by hand is a royal pain, so I recalled a simple little kludge that would get all the bad mail into one queue so it could be deleted in one fell swoop instead of having to right click on every queue and choose "Delete all messages (No NDR)"

The steps are laid out pretty explicitly in a KB article from Microsoft, so I won't go into great detail here. I'll just give you the overview.

All of the following steps are done using the Exchange System Manager. I did this using Exchange 2000, it should work for Exchange 2003. I haven't played with 2007 at all -- three servers?!? -- so I have no clue if this is still how it works.

First, you need to make sure all your good mail is out of the queue, so I tend to do this at 3 AM when I know that it's been a few hours since anyone has tried to send any out-of-office mail and anything I'm going to find in the queue is crap. YMMV.

Next, stop the SMTP Virtual Server for the site.

Create a new SMTP Connector which is going to take all of the junk mail. Make sure the "Address Space" properties are set that SMTP is accepting for * (all domains) at a cost of 1.

Restart the SMTP Virtual Server.

All of the mail should now go into this new queue you created. Right click the queue, choose "Delete all messages (No NDR)"

Refresh the queue list a few times to make sure all messages are gone.

Stop the SMTP Virtual Server.

Delete the SMTP Connector you just made.

Restart the SMTP Virtual Server.

Mail should start flowing as usual.