FPSE and Form Results over Email (SMTP)

I have seen many issues over the past few years when customers try to use the FrontPage Server Extensions (FPSE) to send form results via email, and a recent post to forums.iis.net was enough motivation for me to decide to write a blog about this issue. I've helped a lot of customers to get this scenario working, and with that in mind, I'd like to explain a little bit about the technology involved, its limitations, and what I think is the best workaround for the situation.

When you configure FPSE to send email results over email, you can specify the name of the remote SMTP server and the email addresses for FROM and REPLY TO.

This shortage of settings immediately runs into a problem when your remote SMTP server requires credentials for authentication - you have no way to configure those settings. What's worse, FPSE is a best-case-only email client. When an Internet user clicks submit on an FPSE-enabled form that will send results via email, FPSE will attempt to communicate with the remote server to send the form results. If that communication process fails for any reason, FPSE will simply fail the entire transaction. (Usually with an ugly error message to the client.)

To put it simply, FPSE was not designed with a great deal of reliability or flexibility where email is concerned.

Fortunately, there is a great workaround that is built-in to IIS. Instead of configuring FPSE to send email to a remote SMTP server, what you should do is to install the IIS SMTP server on the local IIS server where FPSE is being used, configure that local SMTP service to forward email to your remote SMTP server, and then configure FPSE to send to the local IIS SMTP service. This yields a great number of benefits - the IIS SMTP service has a large number of configurable options: these settings include include remote security credentials and options that configure the number of retry attempts, alternate ports, logging, non-delivery reports, etc. This environment has the added benefits of increased performance and a much greater success rate. Consider the following:

  • The local IIS SMTP service will quickly respond to FPSE, which will then report to web users that their form results have been saved. This will respond much quicker than FPSE communicating with the remote SMTP service.
  • FPSE will attempt to communicate with an SMTP server only once, and FPSE will simply report an error if that fails. Since the local IIS SMTP service will negotiate with the remote SMTP server with retries, it will function like a message queue server for your FPSE email results even when the remote SMTP service cannot be contacted for some reason.

To configure this environment, use the following steps:

  1. Configure the IIS SMTP service to send to another SMTP server:
    • Open the IIS Manager.
    • Right-click your SMTP virtual server and click Properties.
    • Click the Delivery tab.
    • Click the Advanced button.
    • Specify your upstream SMTP server in the Smart host text box.
    • Click OK to close the Advanced Delivery dialog.
    • Note: If your upstream SMTP server requires authentication, click the Outbound Security button and specify your security options.
    • Click OK to close the SMTP virtual server dialog.
  2. Configure FPSE to use the local SMTP service:
    • Open the Microsoft SharePoint Administration web site
    • Click the Set installation defaults link
    • Specify "localhost" in the SMTP mail server text box
    • Click the Submit button

That's all it takes - FPSE will send emails to the local SMTP service, which will forward them to the remote SMTP service.

I hope this helps! ;-]

No Comments