Sending E-mail from Your MultiValue Programs - Part 4: Using MS Exchange and Sockets

In the last few articles I have shown how to use command-line tools to help you send your e-mail, but many of you probably have MS Exchange or some other e-mail systems that do not provide command-line tools.

There are several open-source and freeware SMTP servers out there that work on both Linux/Unix, and Windows that you can use this method on as well.

How it Works

The main thing you need to keep in mind when using sockets is the SMTP Protocol. This protocol is really simple to implement. If you look at figure 1, you will see the output from a conversation with the SMTP server. Now let's look deeper at each of these lines and commands (fig. 1).

READ: 220 SMTP Server ready 
READ: 250 Hello []
READ: 250 OK <> Sender ok
READ: 250 OK <> Recipient ok
READ: 354 Start mail input; end with <CRLF>.<CRLF>
READ: 250 OK

Fig. 1

The first thing to do is connect to the mail server. You will need the IP address or host name for this as well as the port number the SMTP server is listening on. The standard TCP/IP port for SMTP is 25, but sometimes the server will require you to use a different port to relay e-mail through.

Once you are connected, you will receive a response in the following format "220 hostname SMTP Server read". Keep in mind that all response from the SMTP server will start with a "Message Code", Space and then a "Human readable message". This makes the checking and parsing of success and failure easy to extract with a FIELD statement:


If you get anything other than a "220" when you first connect to the SMTP server, then the server is unavailable to you to send e-mails to. If this happens, you can just close the socket connection at this point.

In order to continue sending, you must introduce your server to the SMTP server. This is done by issuing a "HELO servername". No, the "HELO" is not a typo. If you do your own research into the SMTP protocol, you will also see that a valid response is also "EHLO". The "EHLO" command provides you access to additional SMTP commands and more detailed response codes. For our purpose, we just need the simple commands provided by "HELO".

The SMTP server will now take the server name you supplied with your "HELO" command and do a reverse lookup to make sure it is a valid server on the network. Sometimes this is just lookup in a DNS server to see if the domain, server, or IP address exists. Other servers will actual do sometime similar to a trace route on the IP address to see if the name supplied is the same as what the trace route returns. This is why it is important to provide the correct domain information.

The SMTP server will provide a response code of 250 if it has decided not to block you from sending or relaying. From here on, if you want to close you connect you need to send the command "QUIT" before closing the connection. While you can just close the connection without issue the "QUIT", it isn't nice, and some SMTP servers will remember that and think you are a spammer or hacker the next time you connect to them.

The next few commands you issue tell the server who you are and who the e-mail is going to. "MAIL FROM" and "RCPT TO" commands are used by the SMTP server to decide if you are authorized to continue, and if the server supports relaying to the "RCPT TO" address. Again look for a response code of 250 as a successful response. If you get something other than 250, then issue "QUIT" and disconnect. The SMTP server will sometimes tell you why you have been rejected, so keep a watch on the "human readable" part of the response for this.

The "DATA" command tells the SMTP server that you are about to send the actual e-mail. The server will then accept all the data being sent to it until it receive a single line with only "." on it (<CRLF>.<CRLF>). If your e-mail has a single line with "." on it, add a space to the end of it, or some other character . Once you are done sending the e-mail, send the <CRLF>.<CRLF> to tell the server you are done sending the e-mail.

At this point, the SMTP server will do some additional checks on the e-mail you just sent it to make sure you are not a spammer or hacker. For example, this is when spam assassin or other spam filters happen. It will also check file sizes and other content for restrictions. This is also likely when it checks to see if the person you are sending to is actually valid, rather than during the "RCPT TO" command.

Now all you have to do is issue a "QUIT" command and close the connection. You have just successfully sent an e-mail using sockets.

Database Sockets

Each MultiValue platform provides their own syntax for implementing socket communications. In order to avoid turning the magazine into 15 pages of code, scan the QR code or go online to the digital edition to get access to additional code samples.

Drawbacks to Using Sockets

Sockets are nice since it doesn't require you to rely on the host system to have the tools you need, but there are many features you are missing. The main feature that it lacks is Simple Authentication and Security Layer (SASL).

SASL provides encryption and security when transmitting the e-mail to the SMTP server. It also allows the SMTP server to make sure you are a valid sender, not a spammer or hacker.

Another drawback to sockets is that each MultiValue platform implements them differently. This requires you to create platform-specific programs, which is not likely to be a problem for you, but it can cause problems if you need to support cross-platform applications.

Gmail and Sockets

At one time you could use the socket approach to sending e-mail to Gmail. But now, Gmail requires SASL support. Due to the overhead and system limitations involved with generating encryption, what I'm showing you will not work without relaying through a local SMTP server.


View more articles


Jul/Aug 2011