There is this great free mailserver called hMailServer which can be found here. It is very stable and works definately like a charm. There is some awesome documentation and thus a breeze to configure. I wanted to use this free mail server on my SharePoint 2010 development / demo machine but got stuck with two problems to resolve.
SharePoint can not connect to a mail server that requires authentication. hMailServer is secure by default so you have to add ip-range and define that this ip-range does not require authentication. In my case I defined a range from 0.0.0.0 till 255.255.255.255 and allow message to and from @development.com only. Have a look at the screenshot for were to find these settings and what their value should be.
This one was a bit more complicated. SharePoint requires a path to a ‘drop folder’ where it can find the incoming emails. hMailServer however does not work with drop folders. It creates a folder hierarchy for each account. The dropfolder in the screenshot below is created by me. Just note the folder hierarchy.
bad sender or receiver
Even if you do direct SharePoint to one of those folders inside the hierarchy, it results in a ‘bad sender or receiver’ error when it tries to process the email. But why? It works with the default IIS smtp server right? This error occurs because the default Microsoft SMTP server adds two headers to an email: the x-sender and the x-receiver. SharePoint uses these headers when it processes the emails.
The solution to all this is the use of VBScript. hMailServer can be extended by writing some event handlers.
If we could write a script, that copies an incoming message to a ‘drop folder’ AND add the two headers, we are done. Luckily we can!
First we create a dropfolder inside the existing hierarchy.(Have a look at the screenshot above). Be sure to set the permissions for this folder to allow the SharePoint Timer Service account to make modifications!
Then - after clicking the ‘Show scripts’ button(see screenshot above) - simply open the script file ‘EventHandlers.vbs’ and add the following script.
Sub OnDeliverMessage(oMessage) Dim path, filename, fso, original, copy path = Split(oMessage.Filename, "\", -1, 1) filename = "C:\Program Files (x86)\hMailServer\Data\development.com\dropfolder\" & _ path(UBound(path)) Set fso = CreateObject("Scripting.FileSystemObject") Set copy = fso.CreateTextFile(filename, True) copy.WriteLine("x-sender: " & oMessage.FromAddress) copy.WriteLine("x-receiver: " & oMessage.To) Set original = fso.OpenTextFile(oMessage.Filename, 1) copy.WriteLine(original.ReadAll) copy.Close original.Close End Sub
This should replace the commented Sub OnDeliverMessage(oMessage). Save the script., ‘Check syntax’ to be sure and click ‘Reload scripts’ to enable this freshly added script. The script simply copies ALL incoming mail messages to the ‘dropfolder’ and prepends the two mentioned headers. Now simply point SharePoint to the dropfolder and that’s it!
With this script in place you can very well use hMailServer in combination with SharePoint!
Cheers and have fun,
tip: create a catch all address for all your SharePoint incoming mail. You do not want to manually add a new address for each list you want to mail enable.
Every now and then you run into unexpected SharePoint behavior. The Title field of an item is a 'single line of text' field. In my specific case however this Title field contained a file number. Not a problem at all, BUT you get a really strange sort order when you start to sort numbers as strings. File number 1000 comes before file number 9. This is however expected behavior.
The client wanted to be able to sort the items in a numeric way so I simply created a calculated columns of type number with this expression "=[Title]". Easy peasy right? And that's where the unexpected behavior came along. The field indeed got the value of the Title field, but if I sorted the list by this field, it behaved exactly as if the field contained a single line of text. So again, 1000 comes before 9. Checked if I indeed set the calculated field to be a number and well, I did. The value simply wasn't treated as a number but as text. Strange...
So I started digging in my development experience and I decided to make a little change to the expression. I changed the expression to "=[Title] + 0". And what do you know? The calculated field now indeed returned a number and was treated like a number. Sorting by the field now produced the expected behavior. File number 9 now comes before file number 10000.