This may not be in the right location, so tell me and I'll move it.

I am a recent EE grad and I was hired to build a system that exists on a SoC with a simple 32-bit processor. The system basically monitors several external devices and performs some DSP on it, and then is supposed to send the results using a WiFi device (in my case I have the ESP8266 using UDP) to an email server for logging/notification.

I have been trying to find a library that I can use, but my uC can only program in C and I have it set up for UDP, and everything is in C++ using some other protocol, or something else completely.

I am great at DSP, decent at SoC's and uC's, but when it come to this email server communication thing I am at a loss.

I have successfully configured everything for the sensors, the datapath, the DSP, and connected the system to my WiFi via UDP, but I have yet to figure out how to send data to any servers.

Could someone help me understand how I should go about this?

I have looked into some simple SMTP commands such as HELO, MAIL, RCPT, DATA, etc. but I cannot understand how I actually should implement them in my code.

When I send out the WiFi data via UDP what type of data do I send and how do I format it? Do I need to send any other kind of flags? How should I expect the response? I also know the data has to be transformed into base 64 which is confusing me further.

I am also not super familiar with UDP to begin with, I have been using libraries that are part of the SoC's default library to connect to my WiFi.

I know these may either seem like obvious or stupid questions but it is were I no longer have any knowledge, and everything I find online doesn't make sense, or doesn't attempt to explain it, just gives a pre-made solution

I have found the RFC2821 but it doesn't get any clearer.

I know that's a lot but any help at all would be a lifesaver!

  • 3
    \$\begingroup\$ SMTP is usually used with TCP, not with UDP \$\endgroup\$
    – jippie
    Commented Nov 5, 2015 at 16:42
  • 1
    \$\begingroup\$ I suggest you do this check out the SMTP RFC which is essentially all the info you need on the SMTP protocol tools.ietf.org/html/rfc5321 Then get a mail client on your computer, and install wireshark then send a simple email. You'll be able to watch the whole process bits, bytes, and protocol. That should give you a clear understanding of how this works. \$\endgroup\$ Commented Nov 5, 2015 at 16:47
  • 1
    \$\begingroup\$ another very simple test you could observe is using telnet to send an email. Here's an example technet.microsoft.com/en-us/library/aa995718(v=exchg.65).aspx \$\endgroup\$ Commented Nov 5, 2015 at 16:48
  • 1
    \$\begingroup\$ You might find it easier to send to a PC over UDP and then build a UDP-SMTP bridge in a desktop language like C#. \$\endgroup\$
    – pjc50
    Commented Nov 5, 2015 at 18:59
  • 1
    \$\begingroup\$ You may have trouble still finding a service that will accept and pass on SMTP from an unauthenticated origin (or at least one which isn't going to be blacklisted as a spam source by recipients' providers). At the very least, verify that you have a scheme that can can work by using some simple test code on a PC before you put time into an MCU implementation. There are lots of schemes and services out there for reporting data out of embedded devices which are going to be a lot more friendly to an MCU/ESP8266 implementation, probably including ability to generate an email at the server. \$\endgroup\$ Commented Nov 6, 2015 at 4:57

2 Answers 2


OK, so in order:

  • To send an email, your equipment needs to have an SMTP conversation with a mail server somewhere. In this conversation, your system will be a client to the mail server.

  • SMTP is a protocol which runs on TCP, not UDP. There's no simple UDP equivalent.

  • The very simplest way to understand SMTP would be to look at RFC821, which is very, very old and has been superseded, but still describes the basic principles correctly.

  • TCP is much, much, much more complex to implement than UDP (like a month vs an hour), and if you're struggling to comprehend the SMTP rfcs, you'll find TCP very difficult indeed.

In general, if I need UDP/IP, I just write the code to do it, and if I need TCP/IP, I use someone else's stack (often LWIP on small processors).

Do not make the mistake of thinking TCP is 'some extra effort' vs UDP, it's not at all like that, and is a very big 'some extra'. If you want it to work at all reasonably in the face of the packet loss which you get on WiFi, you need a decent implementation, not just the most basic SYN/ACK stuff.

My advice: start with lwip - if you can't get that going, then you're probably not ready to write the rest of it yourself anyway.

Update: Make sure you see Dave Tweed's comment below - I had not realised that your module had a complete TCP/IP stack in it already - you basically just need to work out how to send and receive lines of text over TCP with it, then you should be able to work through RFC821 (and its successors) to send a message.

  • \$\begingroup\$ Some Ethernet interfaces support protocol offloading, both TCP and UDP (and ICMP, probably others too). These things are reasonably cheap and are much easier to use. \$\endgroup\$
    – jippie
    Commented Nov 5, 2015 at 19:14
  • 4
    \$\begingroup\$ @jippie: The ESP8266 is in fact just such a coprocessor; it should not be necessary to run a TCP/IP stack on the OP's processor at all. Just use it to send it the necessary AT commands after reading the ESP8266 manual. \$\endgroup\$
    – Dave Tweed
    Commented Nov 5, 2015 at 22:54
  • \$\begingroup\$ Thanks for the help, I did not realize this when I bought it, turns out I got lucky though. For 6 bucks its quite the deal! \$\endgroup\$
    – scarlso9
    Commented Nov 11, 2015 at 17:05

There is one more wrinkle in addition to what Will Dean said.

As he said in his point 1, you need to have a SMTP conversation with a mail server somewhere. The somewhere part could be tricky. If this device is going to send thru a dedicated known server, then all you need is to store its static IP address.

However, in the more general case, you need to do a MX lookup on the email address domain to find the server that accepts mail for that domain. The process of finding the right IP address from a email address can be more convoluted than sending the message once you know the server. You have to contact a DNS server, which might give you the information directly, or may pass the buck to another server. These conversations require UDP if I remember right.

To simplify this, you can set up your single known server that all your devices send to. However, since this server will be relaying, you have to protect it so that spammers and other dirtbags can't use it to relay messages thru it. Your devices have to somehow authenticate themselves, and your server must reject connection requests from anything else. SMTP does have the possibility for authentication built in, but the methods that don't require a lot of coding are not very secure. If anyone can take one of your devices and capture packets from it, they could learn how to authenticate to your server. This means you need to implement much more fancy authentication.

If you dispense with a special server, then you have to do the MX lookups, or have the user configure the device to a specific SMTP server ahead of time that accepts messages for the domain the device will be sending to.

It's nowhere near as simple as just having to have a conversation with a mail server.

  • \$\begingroup\$ All this is true, but of course most traditional mail clients don't do any of this either - they're just configured to talk to the company mail server, and the company mail server is configured to trust clients within the company's network. All this can happen without resorting to MX resolution or STMP auth. But I agree with you that for a general 'internet thing', STMP mail isn't a consistently simple way to call home. \$\endgroup\$
    – user1844
    Commented Nov 11, 2015 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.