text.email Now Supports SMTP CHUNKING and BDAT

text.email now supports SMTP CHUNKING and the BDAT command, giving email servers another way to deliver messages to our email-to-text gateway.

This update comes into play when an application, monitoring system, or mail server sends an alert using a format that needs chunked SMTP delivery.

It also addresses a compatibility issue that can affect messages traveling through Microsoft 365: emails containing certain nonstandard line breaks can fail when the receiving server does not support BDAT.

There is no new account setting to enable. Your sending mail server can detect this capability automatically when it connects to text.email.

Why an Email-to-SMS Service Like text.email Needs to Support Different Ways of Sending Email

A text.email notification starts as an email. Before we can turn it into a text message, the system sending that email has to transfer it to our server.

For example, your monitoring application might generate an alert, pass it to your organization’s mail server, and have that server deliver it to your text.email address.

If the email transfer fails, text.email never gets a complete message to process. The phone number can be correct and the alert can be perfectly understandable to a person, but a protocol compatibility issue can still interrupt delivery.

Adding BDAT support expands the ways our server can receive that email. The benefit is especially relevant to administrators connecting existing software to text.email, where the application and mail infrastructure determine how the message is transmitted.

What Are SMTP CHUNKING and BDAT?

CHUNKING is an SMTP extension that lets a sending server transfer an email in one or more chunks. BDAT is the command used to send those chunks.

Each command specifies the exact number of bytes that follows, and LAST marks the final chunk. (The extension is defined in RFC 3030.)

Here is a simplified example. The bracketed descriptions stand in for the actual email bytes; this is an illustration, not a script to paste into a terminal.

Sender: BDAT 1000
Sender: [Exactly 1,000 bytes of message content]
Server: 250 OK

Sender: BDAT 500 LAST
Sender: [The remaining 500 bytes of message content]
Server: [Final SMTP response]

The sender can also transfer the entire email in a single chunk. In our implementation, text.email collects the chunks and passes the assembled email into its existing processing flow after the final chunk arrives. Receiving an intermediate chunk does not trigger an SMS.

How is this different from the usual DATA command?

Traditional SMTP transfers use the DATA command. After the server signals that it is ready, the sender transmits the email and ends it with a line containing a single period. A process called “dot-stuffing” protects periods at the beginning of lines from being mistaken for that terminator. This behavior is described in the SMTP specification.

BDAT uses byte counts to identify chunk boundaries. It does not use that period-based ending or apply DATA-style dot-stuffing. A sender learns whether it can use BDAT from the receiving server’s EHLO response: the advertised capability is CHUNKING.

Our SMTP server now includes CHUNKING in that response. Existing senders using DATA can continue using it, and compatible senders have the additional BDAT option.

Why this matters for Microsoft 365 and bare line feed errors

One practical reason to support BDAT is a delivery problem involving bare line feeds.

Email normally uses a carriage return followed by a line feed, written as CRLF, to end a line. A bare line feed is an LF without the preceding CR. An automatically generated email can contain these line endings even when its visible content looks ordinary.

Microsoft documents an Exchange Online delivery failure with the code 550 5.6.11 when a message contains bare line feeds and the destination cannot accept them. SMTP CHUNKING/BDAT support at the destination is a way to handle this transfer. (Microsoft 365 no longer removes bare line feeds like it used to, in part to better support email security standards such as DKIM. See Microsoft’s explanation of error 550 5.6.11.)

For text.email users, this makes BDAT more than an obscure protocol feature. An automated alert may pass through Microsoft 365 on its way to a phone, and the receiving gateway needs to support the transfer method that the mail system requires.

If an earlier attempt to send an alert to text.email failed specifically because the destination lacked CHUNKING or BDAT support, try that notification again. Other rejection reasons still need to be investigated separately.

What We Added to text.email

Our implementation covers the complete chunked-message transaction, including the boundaries and failure cases that matter when real mail servers communicate:

• Single-chunk and multi-chunk messages. The receiver handles an email sent in one transfer or divided across several BDAT commands.
• Correct handling across chunk boundaries. Chunks are collected as bytes before the assembled content reaches our existing text-processing integration. A multibyte UTF-8 character split between chunks is not decoded separately on each side of the boundary.
• Final-chunk handling. Processing waits for LAST, including the case where a sender finishes with an empty BDAT 0 LAST chunk.
• Message-size enforcement across the whole transfer. Dividing a message into smaller chunks does not bypass the configured total message-size limit.
• Handling of failed and interrupted transfers. Incomplete payloads are not delivered as complete messages. Rejected chunks with known lengths are consumed without treating their content as new SMTP commands.
• Continued support for DATA. Our regression coverage includes separate DATA and BDAT transactions on the same connection.

We added protocol regression coverage for these cases, including delayed network fragments, literal period-only lines inside the payload, transaction resets, and successive messages. These checks exercise the listener’s protocol handling without sending real text messages.

Does “chunking” mean the recipient gets more text messages?

No. SMTP chunks and SMS segments are different things.

SMTP chunking controls how an email travels from a sending server to text.email. SMS segmentation happens later, when text.email prepares the content for delivery to a phone.

An email transferred in ten BDAT chunks is still one incoming email. Those ten chunks do not become ten texts. The outgoing message count depends on the content, recipients, and applicable account settings — not the number of SMTP chunks used to transport the email.

Does this add BINARYMIME or new attachment support?

This release adds CHUNKING and BDAT support. Our server does not advertise BINARYMIME, which is a separate capability described alongside CHUNKING in RFC 3030.

That’s because our downstream integrations process email as text. We are not claiming unrestricted binary-message handling. An email with an attachment delivered through BDAT still goes through text.email’s existing attachment and message-processing features.

So… Do You Need to Take Any Action?

Mostly no, unless you’re still seeing errors.

You can keep sending to your existing text.email addresses like you have been; there’s no toggle in the account settings for SMTP CHUNKING or BDAT. And you don’t need to send to different email addresses.

This all happens behind the scenes: the SMTP conversation between your mail system and our server determines whether the email uses DATA or BDAT.

If you’re the administrator of your sending system, your SMTP logs can help confirm what’s happening: look for CHUNKING in the destination’s EHLO response, BDAT during the message transfer, and the final server response. Note: An acknowledgment of an intermediate chunk only confirms receipt of that chunk; it does not establish that a text has reached the recipient’s phone.

If you’re troubleshooting a failed notification, keep the full bounce message or SMTP error, the approximate sending time, and the sending system’s name. Those details help distinguish an email-transfer problem from a later message-processing or delivery issue.

To use email as a quick and easy way to get text alerts, check out text.email. If you previously ran into a BDAT-related delivery failure, this is a good time to retry your integration.