It would appear that Sitecore’s mail settings are, mostly, in a handful of settings in web.config. At one level, they are, and a simple patch file can be used to set them for your system. For example… 

<?xml version="1.0"?>
<configuration xmlns:x="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<setting name="MailServer" value="">
<x:attribute name="value">smtp.example.com</x:attribute>
</setting>
<setting name="MailServerUserName" value="">
<x:attribute name="value">xxxx@example.com</x:attribute>
</setting>
<setting name="MailServerPassword" value="">
<x:attribute name="value">xxxx</x:attribute>
</setting>
<setting name="MailServerPort" value="">
<x:attribute name="value">25</x:attribute>
</setting>
</settings>
</sitecore>
</configuration>

Well, okay, that works. Most of our customers have Sitecore’s Web Forms for Marketers module, though and this makes matters a bit more complicated…

Firstly, many of the Save Actions are defined with their own mailserver settings. You’ll need to edit them inside Sitecore itself. You’ll usually find them under:

/sitecore/system/Modules/Web Forms for Marketers/Settings/Actions/Save Actions/

… and you’ll need to set the parameter’s field to an XML string describing your connection. There’s a good description of this here: http://blog.arkesystems.com/post/2010/05/18/SiteCoreWeb-Forms-for-Marketers-Send-Email.aspx

For example, my string for an example system that is using Google is:

<Host>smtp.gmail.com</Host><Port>587</Port><Login>example@example.com</Login><Password>xxxxx</Password><From>example@example.com</From><IsBodyHtml>true</IsBodyHtml><enableSSL>true</enableSSL>

Lovely. And yes, this is using SSL to connect.

The second problem is that Web Forms For Marketers forms can be exported as User Controls (.ascx files) that we can then edit the code for. Thus, these save actions are encoded into the .ascx file – and they then contain the encoded settings for a save action to send emails with. For example, this is the code for one:

There’s quite a lot of code behind one of these – roughly 5Kb, most of which is the encoded details about the mail message to be sent. It’s HTML encoded – decoding it gives us something like:

<host>localhost</host><from>example@example.com</from><isbodyhtml>true</isbodyhtml><to>info@example.com</to><cc></cc><bcc>example@example.com</bcc><subject>Website Contact Enquiry</subject><mail><p>Reason: [<label id="{18AB7100-486E-4067-99A9-F9E24D30E2A8}">Reason</label>]
... Many metadata fields...
</p></mail>

I’ve chopped that slightly – so that we don’t have reams of code building our mail body from our from fields – but you can spot the problem – the email addresses for our WFFM form are now tucked away in an encoded string, inside a user control. Naturally, this will also need updated if you want to change the address an email goes to.

So that’s a third place that email settings need to be configured – and I’ve not looked at Email Campaign Manager yet.