Okay, that might be a bit of an exaggeration. Unfortunately, setting up this feature wasn’t as easy as the documentation suggested. Then again, is it ever that way!?
Incoming e-mail is a feature which allows users to e-mail an address and have the content of that e-mail appear in a document library, discussion board, or any other list supported under SharePoint.
In my opinion, this is an extremely valuable piece to the SharePoint deployment puzzle. I would go so far to say that it is a crucial piece to every SharePoint configuration.
Let’s face it. Most people communicate widely via e-mail. To leave that source of knowledge and documentation nested in a neat folder within your inbox, is downright neglegent! Plus, most end-users have been trained, and have become comfortable, with navigating your e-mail system. Outlook (or any other mail client) is the perfect front end to encourage users to post their information into their respective SharePoint site.
But, of course, you know all this.
Why then, was this crucial piece of configuration such a BEAR to setup? Two reasons:
1. Microsoft needed to make this configuration path a little more clear, consistent, and stable.
2. I need to learn just what the heck I’m doing!
So in order to enrich the community (and help me remember how I did all this), I give you my steps for setting up incoming e-mail on a discussion board list:
NOTE: If you are not the demi-god of your IT dept and do not have access to everything, know that you are going to have to get a couple people involved. Namely, the person that supports your Active Directory structure and the person that supports your DNS server (probably the same person [maybe it's you!]). You will also have to have access to configure the web front-end server of your SharePoint configuration running Central Administration. Hopefully you at least have access to that. If you don’t, I shed a tear for you. I know you cringe at the thought of having to ask your network administrator for help, but just bite the bullet and walk over to his/her desk and beg mercilessly for his/her help.
1. The first thing I did (ahem my network admin. did) was create an Organizational Unit (OU) called “SharePoint Distribution” in the local domain of our Active Directory Schema. He placed this OU under the OU called “Groups” (don’t ask me why, that’s his job!)

2. He then right-clicked on the SharePoint Distribution OU and selected “Delegate Control…”. This opened the Delegation of Control Wizard. He specified the user name of the account that is running the application pool for our Central Administration.
NOTE: If you don’t know what your’s is, go to the front-end web server that is running your CA and under IIS > (your server) > Application Pools, find your the Application Pool that is running your CA. Right-click > Properties… and click on the Identity tab. The user name specified here will be the account that you are going to want to use. Ours is “sp_farm”.
Back to the Delegate Control wizard.
He added “sp_farm” as the account, clicked Next and specified “Create a custom task to delegate”, then selected Next.
Under the Active Directory Object Type screen, he selected: “This folder, existing objects in this folder, and creation of new objects in this folder”, then selected Next.
Under the Permissions screen, he selected “General”, “Property-specific”, and gave the sp_farm account “Write” access.

Now the sp_farm account has the ability to create contacts in the SharePoint Distribution OU.
3. Now we needed to configure our DNS server. I had him create a dns record entry for sharepoint.<our_internal_domain>.org and had him point it to the IP Address of our web front-end server running CA.
4. I then logged on to the web front-end server, stopped the Default SMTP Virtual Server, then completed the following steps:
A. Right-click on Default SMTP Virtual Server > New > Virtual Server…
B. Name: sharepoint.<our_internal_domain>.com > Next
C. All Unassigned > Next > Answer “Yes” to the prompt that comes up
D. Home Directory: C:\inetpub\mailroot
E. Domain: sharepoint.<our_internal_domain>.com > Finish

5. I then had to log into Central Administration. Under Operations > Topology and Services > Incoming e-mail settings I specified the following parameters:

NOTE: Under “Active Directory container where new distribution groups and contacts will be created:” I specified:
“OU=SharePoint Distribution,OU=Groups,DC=<servername>,DC=local”
6. I’m finally ready to set this thing up! So I went to my SharePoint site and navigated to my discussion board list. In this case, I am working with a Discussion Board for our Database Team. I then selected Settings > Discussion Board Settings.

I then clicked on the link “Incoming e-mail settings” under the communications heading. I configured the following parameters:

In this case, I have configured an e-mail address of dbaod@sharepoint.<our_internal_domain>.org to be used for this discussion board list.
Upon, selecting OK, it then….
BAM! (Melodramatic music playing)
I got a blanket “Error in application” response from SharePoint. Hmmmm, yes…very descriptive.
“There must be some sort of permission issue!” I thought. After hours and hours (did I say HOURS?) of frustrating blowing away and re-configuring, all it took was a simple restart of my web front-end server. You know the one that is running CA? Anyway, that is what worked for me.
Conclusion:
Now that it is working. When I click OK to save the “incoming e-mail settings” on my discussion board settings page. The contact “Database AOD DBA AOD Discussion Board” gets created under the “SharePoint Distribution” OU. It takes some time but, eventually, the e-mail address of “dbaod@sharepoint.<our_internal_domain>.org” get specified in the properties of this contact as well.

Now when an e-mail is sent to this address, an .eml file gets generated and sent to the drop folder on our Web front end server (you know, the one running CA). An SPTimer service grabs that file and posts it up on the appropriate SharePoint list. This process takes about 60 seconds for us.
By the way, Todd Klindt’s Blog has some useful information on all of this. Also, the white paper from Combined Knowledge is very helpful.