Spludlow Web Header

Email with the Spludlow Framework

Mail Section Contents

Send Sending Email
SMTP Simple Mail Transfer Protocol
Receive Receiving Mail
Exchange Exchange API

Mail within you application

Email interaction is often an important part of online applications. Whether it’s to register a web account, proving you own the email address, or sending out order and despatch confirmations your application is going to want to use email in some form.

Most of the time your application only sends out emails, your ISP may provide an SMTP server that you can use, or you use a third party. If this is the case then you can do it that way.

But there may be circumstances where this won’t do, maybe restrictions on the ISP SMTP server like message size or number of messages, or you may want to handle incoming messages. Maybe they ban you after sending out too many bulk marketing mails.

The framework does not attempt to provide a general email solution for users within an organization, like an email server such as Exchange, but will help with your application to both assemble, send, receive, and extract email.

Let’s run though some basic concepts of mail, how to set up a server and configure it, and then what the Framework provides regarding email.

WARNING: Don’t mess with you existing DNS MX records it will break your organizations mail. If you want to test an application that receives mail then create a sub email domain like @app.mycompany.com and leave your existing MX records as is.

Writing Code that deals with Mail

Let’s go through some of the available technologies that deal with mail.

System.Net.Mail (Create & Send Mail)

The .net Framework’s namespace containing classes to send SMTP mail. Everything you need to construct and send SMTP mail.

Build a message, either text or HTML, add attachments if required, setup the addresses and subject then use the SMTP client to connect to an SMTP server and send the message.

These classes are very simple to use directly the Spludlow framework provides some simple wrapper methods to handle configuration and allow sending in one static method call.

NOTE: You can configure the mail client to send mail to a directory rather than a real SMTP server, handy for testing, configure with the “specifiedpickupdirectory” setting.

System.Web.Mail (deprecated)

Use System.Net.Mail not this. Used in the early days of .net, wrapper for Collaboration Data Objects for Windows 2000 (CDOSYS) until they re-wrote the sending email code.

CDOSYS - Collaboration Data Objects for Windows 2000 (Parsing received MIME Mail)

Extracting the components of a standard MIME mail, the file that is dropped by a SMTP server, is something that your application may want to do, perhaps you want to automatically pull the attachments from a message or automatically send a reply.

As it stands .net provides no way of doing this, there are various third party libraries you can try, how well they work is another matter. Writing your own code to parse MIME messages is no trivial matter.

Say hello to CDO for Windows 2000, it is a COM (pre .net) component that is built in to Windows. It is old but includes a robust MIME parser. Provided you use it correctly it works like a charm.

The Spludlow framework provides a wrapper for the CDO MIME parser to make using it simple.

EWS - Exchange Web Services Managed API (API for Exchange Server)

A standard .net DLL that provides everything you need for your application to work with Exchange server.

The Spludlow framework provides a wrapper to simplify some actions.

EWS - Exchange Web Services SOAP (SOAP API for Exchange Server)

The managed API, mentioned above, is a wrapper for the SOAP EWS that runs on the Exchange server. There are a few methods that haven’t yet been implemented in the managed API so you will have to talk directly to the server in SOAP.

The Spludlow framework provides a wrapper to simplify some SOAP actions.

Microsoft.Office.Interop.Outlook (Reading Outlook .MSG & .PST files)

MSG (Individual message) and PST (Outlook data file containing many messages) are proprietary (although the formats are published) data files used by Outlook. If you want to read them then this .net wrapper can be used.

This interop library controls Outlook, like a puppet, and allows you to perform various tasks in code that Outlook does. Outlook needs to be installed and is actually started when you call the code.

Using Outlook in this way is only suitable for creating utility programs that are ran by a logged in user. I was unable to get it working as a server process, although it may be possible.

Spludlow Web Footer