I am trying to submit a Web Browser Form to a document library in another web application which has incoming email enabled. So far I have identified two problems with this:

  1. SharePoint 2010 doesn't allow email messages with the X-Mailer value including "SharePoint" (this value is set by InfoPath/SharePoint) to be imported.
  2. SharePoint apparently doesn't allow the email message content-type (mime type) "multipart/related" to be imported.

I've tried getting around this with VBScript in the form of smtpreg and an additional "OnArrival" filter that removes the X-Mailer header. However, changing the content type is either really difficult or impossible using the VBScript method.

People talk about sending emails using the FormCode of an InfoPath form, but I am not seeing how to send an email using System.Net.Mail and still include the form data as an attachment, like the normal email submit. My guess is that if I send the attachment using System.Net.Mail I can either set the mime type for the email message manually, or it will default to multipart/mixed instead of multipart/related.

How can I make this happen or is it even possible? I am open to solutions that involve either the VBScript approach or the FormCode/CodeBehind approach for InfoPath.

  • Maybe I'm missing something, but why do you need to email it if you are submitting it to a form library? Just submit it to the document library as a form and promote any form fields you need to columns. – Eric Alexander Apr 2 '13 at 18:27
  • There is a method to my madness, and perhaps it makes the whole thing pointless: the library is in a different web application, AND anonymous users will be the ones submitting the form. I read it was a bad idea to elevate the permissions of anonymous users so rather than do that I was hoping to use the email submit option but ran into the problems above – Matt Apr 2 '13 at 19:04
  • 1
    In either case you are giving anon users the ability to submit items to a library. As long as you give users permission to submit on the web app and have the proper source query string parameters (or use a form web part) they won't hit your other web app. If you don't want to do that, then you could always promote the data that you need to a temp library then use a workflow to email your other web app with the column data merged in. – Eric Alexander Apr 2 '13 at 19:57

In the end this doesn't seem like a viable solution without high levels of customization. I ended up changing directions and going with the Form Code option and just elevating the permissions and submitting directly to the Library instead of messing around with all this email stuff. The results are similar to having the email solution working and they are about equally likely to be abused.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.