Using IIS SMTP Server as a generic mail receiver


Summary

An IIS SMTP server can be configured to silently delete or archive messages as the end point in a message route for a test lab.  IIS SMTP archives messages by default for alias domains and uses performance counters to track statistics.  A simple CDO script can be used to delete the messages instead of archiving them.

Setting up IIS SMTP server

Windows 2000 server, Windows 2003 server, and Windows XP Professional include a SMTP server as part of IIS.  This is the same protocol engine as that used for Exchange.  Once the SMTP server is installed, the server must be configured to accept mail for the domains used in the test lab. 

To add a domain:

  1. Start Internet Information Services (IIS) Manger from Administrative Tools.
  2. Expand the SMTP Virtual Server and select the Domains container.
  3. Right click on Domains and select “New -> Domain…”.
  4. Select “alias” domain type and add the name FQDN of the test domain.

Repeat steps 3 and 4 for each test domain to be used.  If a test domain is not added, the server will refuse to accept mail for the domain.  Detailed instructions for creating and deleting SMTP domains can be found in Managing SMTP Domains.

The server is now configured to archive all mail sent to the domains added above in the SMTP VSI’s drop directory (%SystemRoot%\Inetpub\MailRoot\Drop for default).

If the mail is not needed to be archived, then see the next section for automatically deleting messages using the OnArrival Sink.

Managing Message Deletion Sink

Sinks are used to change behaviors of the SMTP server.  The following vbscript example marks for deletion any message that is called for, and then aborts calls to any other sink.

<SCRIPT LANGUAGE=”VBScript”>

Sub IEventIsCacheable_IsCacheable

  ‘ just returns S_OK

End Sub

 
Sub ISMTPOnArrival_OnArrival(ByVal iMsg, EventStatus )

  On Error Resume Next

 
  ‘ CDO constants

  Const cdoSkipRemainingSinks = 1

  Const cdoStatusAbortDelivery = 2

 
  Set Flds = iMsg.EnvelopeFields

  Flds(“http://schemas.microsoft.com/cdo/smtpenvelope/messagestatus”) = cdoStatusAbortDelivery

  Flds.Update
  EventStatus = cdoSkipRemainingSinks
  iMsg.DataSource.Save
End Sub

</SCRIPT>

More information on implementing sinks for SMTP can be found in Implementing SMTP Event Sinks for CDO.

Save the script as DeleteMsg.vbs on the IIS SMTP server in

%SystemDrive%\InetPub\AdminScripts.  This is not a required location, but makes it easier to track.

The next step is getting the Event Management Script and saving it as smtpreg.vbs in the same location as DeleteMsg.vbs.  This script will allow you to add, remove, and enumerate sinks on the IIS SMTP server.

The final step is registering the sinks.  More detailed information can be found in Managing Event Bindings.

To add the sink, do the following:

  1. Go to %SystemDrive%\InetPub\AdminScripts
  2. cscript smtpreg.vbs /add OnArrival DeleteMsg CDO.SS_SMTPOnArrivalSink “mail from=*”
  3. cscript smtpreg.vbs /setprop OnArrival DeleteMsg Sink ScriptName “:\Inetpub\AdminScripts\DeleteMsg.vbs”

To remove the sink, do the following:

  1. Go to %SystemDrive%\InetPub\AdminScripts
  2. cscript smtpreg.vbs /remove OnArrival DeleteMsg

Once this sink is in place, no messages will be dropped into the Drop directory (messages are deleted OnArrival).

Monitoring Server with Perfmon counters

Perfmon.msc can be used to monitor the performance of the IIS SMTP server using the built in counters for SMTP Server Object.  Messages Received Total can be used to track the total number of messages submitted.  The SMTP Server Object can also be used to track bytes and averages.  The counters can be reset by stopping and starting the SMTP VSI under the IIS Manager.

Accept and Delete All Domains (Advanced)

WARNING: The following settings should only be set in a test lab.  Enabling this on a production machine can possible allow remote users to use your server as an open relay.  See HOW TO: Prevent Mail Relay article for more information.

If there is no need to archive messages and it is desired that the sink not be configured for a particular domain, then the server can be configured as an open relay to accept mail for all domains.  The sink will then delete the message as they come in, thus preventing the messages from actually being delivered. 

To configure this:

  1. Follow the instructions under the Managing Message Deletion Sink section to add the sink.
  2. Start the IIS Manager and right click on the SMTP VSI and select properties.
  3. Select the Delivery tab > Advanced
  4. Set Smart host to fake machine name.  This will ensure that messages will not route to their real domains if the sink is removed.
  5. Select the Access tab > Relay
  6. Select “All except the list below”
  7. Select “Ok” twice

James Webster


Comments (4)
  1. Anonymous says:

    Exchange-faq.dk – Din portal til Microsoft Exchange Server information

  2. Luke Edson says:

    I am in the process of migrating from Exchange 5.5 to Exchange 2003 for a company that has multiple small (less than 5 users) branch offices.

    They want to migrate slowly, so here’s my dilemma: The current Exchange 5.5 will still be active for a while. I’m using the Exchange Migration Wizard in Exchange 2003 to migrate the mailbox data over.

    All incoming mail needs to be split between the two servers, as the new Exchange 2003 server will be gradually hosting more & more of the users.

    Can you point me in the right direction if a sink has already been written, to route some recipients to one server, & others to the other? Thanks!

    I can’t join the Exchange 2003 server to the same Exchange 5.5 site, as it’s in a different domain.

  3. KC Lemson says:

    Luke, you added this comment here as well as on dlemson’s blog… this usually causes two people to duplicate the same work as they try to help out, so in the future I would recommend putting the comment in one place, and linking to that one place from other pages as necessary.

    I’m sure you saw that David responded this morning: http://blogs.msdn.com/dlemson/archive/2004/03/03/83304.aspx

Comments are closed.