The mime-mail package allows you to create multipart messages and renders them to lazy ByteStrings. It comes built in with support for using the sendmail executable for actually sending the messages. This is not always the ideal delivery mechanism because:

• It doesn't work on Windows.
• In theory, some MTAs may not supply a sendmail executable. However, I think all the common ones do.
• It doesn't support the situation of having a mail server on a separate system.

It would be good to have a separate package that can handle sending of the lazy ByteStrings that mime-mail produces. The two candidate packages for this are SMTPClient and HaskellNet. I have no experience with either, except to know that SMTPClient currently uses Strings instead of ByteStrings.

Another feature that would be very nice to have for an SMTP library would be SSL/TLS support. When I added this support to the http-enumerator, I use cabal flags to switch between an openssl backend and a backend using the tls pure-Haskell package.

The final point is whether the sendmail function should remain in mime-mail or be moved elsewhere. It introduces a dependency on process, which doesn't seem too bad since that package is shipped with GHC. It also might give users the impression that mime-mail only works with sendmail. However, documentation might address that.

Below is the content of an email I received from Donn Cave. He doesn't have an account on Haskellers, so I asked his permission to reproduce it here:

Well, don't think I have a haskellers account, but between SMTPClient
and HaskellNet (if those are the choices), it looks to me like you
would be better served by HaskellNet.

From extremely superficial analysis, SMTPClient seems mis-designed
to me, in that its "Message" data type is all parsed out - when SMTP
doesn't care.  An email message should for sure be composed of
correctly formatted headers and body, and some of the information
in the headers also goes to SMTP - but it doesn't strictly have
to match (the very message I'm replying to here for example omits
the SMTP recipients from the header.)  The SMTP "envelope" really
is different data, than the RFC822 headers and body enclosed
inside it, and SMTPClient seems to confuse the two.

In my own application, for I guess historical reasons I have
an external SMTP process, so it's convenient to supply the email
data as a disk file.  Since MIME attachments can be very large,
there may be other advantages to that approach in any case.