We have a client that makes use of the Send Email Message Save Action with WFFM 8.1 r 150323. The problem is that the mail server responsible for sending the email is horribly slow. While this is a problem in and of itself, I was curious if there was a solution to get around the deficiency.

It seems that there are two options:

  1. Find a built-in option to solve the problem.
  2. Modify the processMessage pipeline to replace SendEmail with a custom sender that kicks off a Sitecore Job which sends the email.
  3. Modify the processMessage pipeline to replace SendEmail with a custom sender that stores the required information, and implement an agent which reads these and processes unsent messages in bulk.

I don't think a built-in solution exists, but it's worth a try. Barring a small miracle, does anyone have a preference for the custom processMessage idea, or another solution?

  • What is the problem? That the form submission/confirmation is slow as a result of waiting for the message to be sent? Can you also confirm the WFFM version, it's not listed on the WFFM page.
    – jammykam
    Aug 9, 2017 at 18:33
  • @jammykam the issue is that the SMTP can take a very long time to send (and may time out), which causes the entire submission to hang. The correct version is 8.1 160523. I briefly had trouble reading apparently... Aug 9, 2017 at 18:37

2 Answers 2


Since WFFM 8.0 Update-3 the module no longer uses the "remoteWfmService" web-service and instead uses the event queue via the Core database to communicate. From the release notes:

The WFFM security for multiserver configuration has been improved. Sitecore EventQueue is now used and the "remoteWfmService" web-service has been removed.(24829)

This change brings with it the ability to perform a Save Action on the CM server, effectively meaning that the Send Email action is deferred and processed at a later stage, allowing all other save actions to process and the form submission to continue as normal.

Assuming you have followed the installation guide correctly, in particular section "1.2.2 Configuring the CD server", one of the steps listed is:

In the \Website\App_Config\Include\Sitecore.Forms.Config file,

  • Add the following node to the section: <setting name="WFM.IsRemoteActions" value="true" />

Now on your Send Email Save Action ensure that Client Action is not checked.

Save Action

If this field is checked, it will cause the Save Action to run immediately on the CD server. Leaving it unchecked means it is added to the Event Queue and processed by the CM server.

You can read more in the save action item fields document:

Client Action

This field is only used in the staging environment. If this check box is cleared, this save action is transferred from the Slave to the Master server and is performed there. If this check box is selected, a save action is performed on the Slave server.

This should ensure that the form submission occurs immediatelty and any delays due to the mail server are not visible to the user.

  • Good catch! WFM.IsRemoteActions isn't set on the CD machines. We inherited this implementation and haven't had a chance to finish our audit of the implementation yet. I'll make that change and hopefully that should resolve the issue. Aug 9, 2017 at 18:58
  • I think this is the correct way to do it. Unfortunately, turns out that there are other configuration issues with how WFFM was installed, but this is the direction I needed. Aug 10, 2017 at 3:35

Out of the box

I think you're right. I don't know of any way to make WFFM Save Action run async either.

Override SendMail

I wouldn't create a job. I would probably just override SendEmail to fire off the message async, like described (among other places) here: https://stackoverflow.com/questions/8747483/proper-way-to-asynchronously-send-an-email-in-asp-net-am-i-doing-it-right

In essence, something along these lines:

using (var smtpClient = new SmtpClient())
    await smtpClient.SendMailAsync(message);

Custom sender, processor, bulk and so on

This, I believe, would be overkill. But there is an out-of-the-(Windows)-box solution you could consider.

Use the local SMTP service available on any Windows machine. Configure it to act as a relay to the real SMTP service (the slow one). The built-in one stores mails locally, and will dispatch them as quickly as it can. In essence doing the steps you considered yourself.

See also:

  • Thanks for the suggestions Mark! My only concern with your SendMailAsync suggestion is that it while it wouldn't block anymore, the await would still block the pipeline, which would still cause the submission to wait until the email is sent. By asynchronous, I meant that the submission would go through and not depend on the email sending to complete. Your suggestion re: the SMTP relay also looks promising, I was too focused on the Sitecore side of things to remember that setting. Aug 9, 2017 at 15:28
  • 1
    Yep I know. But you can't risk the Save Action being Dispose()'d before it's done. That said; you should not rely on an outside service to begin with, slow or otherwise - you would not want your site to start failing if the external mail server breaks down. Which leads you down road #3 - where my suggestion is only one of potentially many. Message Queues is another option. Aug 9, 2017 at 15:33
  • That said, you could probably omit "await" in this case, and simply return. But then you'd be in real trouble if the SMTP server started failing; no one would ever know. Aug 9, 2017 at 15:34
  • I think your solution about handling this outside of Sitecore is the way to go. I do wish, though, that the timeout set on the SmtpClient in the stock WFFM action was set to something reasonable. The default timeout of 100 seconds seems ridiculously large for a form submission. Aug 9, 2017 at 15:36
  • Yes. And unfortunately it does not appear to be something you can easily specify in the Parameters field or otherwise. Found this gist though: gist.github.com/lowedown/7f98ec0b3e3f2341ba21 Aug 9, 2017 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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