Can You Send Email Over LoRaWAN or MeshCore?

The question came up in the context of the self-sufficiency piece on MeshCore: if the internet is down and you need to communicate with someone, can you send them an email over the mesh? It is a reasonable question. Email is how most people think about written communication. Mesh radio is what you have when the internet is gone. The overlap seems obvious.

The honest answer is: it depends entirely on what you mean by email. If you mean SMTP, TLS handshakes, MIME encoding, and headers — no, not really. If you mean “a written message delivered to a specific recipient who can read it later” — then yes, both LoRaWAN and MeshCore can do versions of that, though neither calls it email.

Working through why clarifies both the constraints of the protocols and what they are actually good for.

The bandwidth problem

LoRa modulation is designed for range and battery life, not throughput. A typical LoRaWAN packet carries a payload of between 11 and 242 bytes depending on the spreading factor and regional parameters. At the spreading factors used for long-range communication in Europe — SF10 or SF12 — the usable payload is at the low end of that range, around 50 bytes. Time-on-air for a 50-byte packet at SF12 can be several seconds.

SMTP, the protocol that moves email between servers, involves a multi-stage handshake. The client greets the server, the server responds, credentials are exchanged, the envelope is set (sender, recipient), and then the message body is transmitted. A minimal SMTP conversation to deliver a five-word message might involve a dozen round trips and several hundred bytes of protocol overhead before the message content even starts. Then the message itself: headers for date, sender, recipient, subject, message ID, and MIME type easily add another 200 to 400 bytes before the body. A “Hello, are you safe?” message, which is six words, might arrive at a mail server as a 600-byte object.

At LoRaWAN SF12 payload limits, delivering that 600-byte email would require fragments across multiple packets, with round-trip acknowledgement for each one, and a duty cycle that limits how often you can transmit. The time required to deliver a single short email over a LoRaWAN link would be measured in minutes. The complexity of implementing SMTP fragmentation over a duty-cycled radio link is substantial. Nobody does this in practice, and there is a good reason.

MeshCore is different but not dramatically so

MeshCore operates over the same LoRa physical layer, which means the same bandwidth constraints apply at the radio level. A MeshCore message is short text, designed to fit within the constraints of the medium. The protocol does not attempt to implement email semantics on top of LoRa. It implements a purpose-built messaging protocol that accepts the constraints of the physical layer and works within them.

Where MeshCore gets interesting for the email analogy is the room server. A room server is a MeshCore node that stores messages and forwards them to recipients when they connect. This is asynchronous, store-and-forward messaging — which is, structurally, what email actually is at its core. The form is different: short text rather than MIME-encoded multipart messages, no subject lines, no attachments, no threading metadata. But the behaviour — send a message, recipient collects it when they next connect, message persists until they do — is email-like in the way that matters for most practical purposes.

The room server’s store-and-forward capability is the closest thing MeshCore has to an inbox. You send a message to a room, the room server holds it, the recipient connects to the mesh and retrieves their messages. For the self-sufficiency use case — communicating when the internet is down — this covers the practical need that email usually serves, within the constraints of what LoRa can carry.

The precedent: Winlink

The amateur radio world has been doing email over low-bandwidth radio for decades. Winlink is a global radio email network that allows licensed amateur radio operators to send and receive internet email over HF and VHF radio, including connecting to the internet when a gateway is available and operating entirely radio-to-radio when it is not.

Winlink uses the VARA and ARDOP modes for HF and Packet Radio for VHF/UHF. These are not LoRa. They operate at higher bandwidths than LoRa and with different modulation schemes. But the concept is directly analogous: email, or something functionally equivalent to it, delivered over a low-bandwidth radio path, with store-and-forward nodes acting as intermediate mail servers.

Winlink clients can compose messages in a stripped-down email format — to, from, subject, body — and the system delivers them either to internet email addresses when a gateway is reachable, or stores them for radio-to-radio delivery when it is not. Attachments are possible but strongly discouraged over HF due to bandwidth. The practical constraint is the same: the protocol is adapted to the medium, not the other way around.

There is no Winlink equivalent for LoRa. The bandwidth available on LoRa is lower than HF radio in most operating modes, which makes even Winlink’s stripped-down email format a stretch. But the existence of Winlink demonstrates that the concept is sound: you can build something that behaves like email over a low-bandwidth radio path if you are willing to strip the format down to what the link can carry.

What LoRaWAN can actually do in this direction

LoRaWAN is primarily a sensor network protocol, not a messaging protocol. That said, there are practical applications in this space. ChirpStack supports downlink commands to devices, which means a server with internet access could receive an email and translate its content into a LoRaWAN downlink to a specific device. Similarly, a device could transmit an uplink that a gateway-connected server receives and forwards as an email. This is a LoRaWAN-to-email bridge, not email over LoRaWAN, but for the practical use case — a device in a remote location that needs to send an alert to an email address — it works cleanly.

The limitation is the gateway dependency. This bridge model requires a gateway with internet access. If the internet is down and the gateway cannot reach the mail server, the bridge does not function. LoRaWAN is not a peer-to-peer protocol; it requires the network server infrastructure. For the resilience use case, where the value is in working when the internet is unavailable, LoRaWAN is the wrong architecture. MeshCore, which is peer-to-peer and requires no internet access to function, is the right one.

The practical answer

For sending an alert from a remote sensor to an email inbox when internet is available: LoRaWAN with a gateway-to-email bridge works cleanly. This is a well-established pattern and it is what the ChirpStack and Home Assistant integration in this series is designed for.

For communicating with another person when the internet is down: MeshCore’s short text messaging and room server store-and-forward cover the practical need. It is not email in the SMTP sense, but it is asynchronous written communication delivered to a specific recipient, which is what email is for.

For actually running SMTP over LoRa: the bandwidth constraints make it impractical for anything beyond toy implementations. The protocol overhead alone exceeds what LoRa can comfortably carry at long-range spreading factors, and the duty cycle restrictions would make delivery slow enough to be useless.

The deeper point is that email is not a single thing. It is a protocol stack — SMTP, MIME, IMAP — layered on top of the underlying need, which is to get a written message to a specific recipient. The protocols were designed for networks with abundant bandwidth. Adapting them to LoRa is fighting the medium. Building something that serves the underlying need within the medium’s constraints — which is what MeshCore’s messaging model does — is the more useful approach.

Where this is going

The MeshCore project explicitly lists post office features as a premium capability: message store-and-forward, group chats, shared calendars. The direction of travel is toward richer asynchronous communication primitives, not toward implementing SMTP. That is the right direction. The constraints of the physical layer are fixed; what can be built on top of them is a design problem, and the solutions that work are the ones that accept the constraints rather than fight them.

Email over LoRa, in the SMTP sense, is a dead end. Email-like communication over LoRa, designed for the medium, is both achievable and already happening.