{"id":794,"date":"2026-10-02T04:05:56","date_gmt":"2026-10-02T04:05:56","guid":{"rendered":"https:\/\/text.email\/blog\/?p=794"},"modified":"2026-10-02T06:43:00","modified_gmt":"2026-10-02T06:43:00","slug":"smtp-chunking-and-bdat","status":"publish","type":"post","link":"https:\/\/text.email\/blog\/smtp-chunking-and-bdat\/","title":{"rendered":"text.email Now Supports SMTP CHUNKING and BDAT"},"content":{"rendered":"\n

text.email now supports SMTP CHUNKING and the BDAT command<\/strong>, giving email servers another way to deliver messages to our email-to-text gateway.<\/p>\n\n\n\n

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

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.<\/p>\n\n\n\n

There is no new account setting to enable<\/strong>. Your sending mail server can detect this capability automatically when it connects to text.email.<\/p>\n\n\n\n

Why an Email-to-SMS Service Like text.email Needs to Support Different Ways of Sending Email<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

For example, your monitoring application might generate an alert, pass it to your organization\u2019s mail server, and have that server deliver it to your text.email address.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

What Are SMTP CHUNKING and BDAT?<\/h2>\n\n\n\n

CHUNKING<\/strong> is an SMTP extension that lets a sending server transfer an email in one or more chunks. BDAT<\/strong> is the command used to send those chunks.<\/p>\n\n\n\n

Each command specifies the exact number of bytes that follows, and LAST<\/code> marks the final chunk. (The extension is defined in RFC 3030<\/a>.)<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Sender: BDAT 1000\nSender: [Exactly 1,000 bytes of message content]\nServer: 250 OK\n\nSender: BDAT 500 LAST\nSender: [The remaining 500 bytes of message content]\nServer: [Final SMTP response]<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
How is this different from the usual DATA command?<\/h3>\n\n\n\n
Traditional SMTP transfers use the DATA<\/code> 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 \u201cdot-stuffing\u201d protects periods at the beginning of lines from being mistaken for that terminator. This behavior is described in the SMTP specification<\/a>.<\/p>\n\n\n\n
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\u2019s EHLO<\/code> response: the advertised capability is CHUNKING<\/code>.<\/p>\n\n\n\n
Our SMTP server now includes CHUNKING<\/code> in that response. Existing senders using DATA<\/code> can continue using it, and compatible senders have the additional BDAT option.<\/p>\n\n\n\n
Why this matters for Microsoft 365 and bare line feed errors<\/h3>\n\n\n\n
One practical reason to support BDAT is a delivery problem involving bare line feeds<\/strong>.<\/p>\n\n\n\n
Email normally uses a carriage return followed by a line feed, written as CRLF<\/code>, to end a line. A bare line feed is an LF<\/code> without the preceding CR<\/code>. An automatically generated email can contain these line endings even when its visible content looks ordinary.<\/p>\n\n\n\n
Microsoft documents an Exchange Online delivery failure with the code 550 5.6.11<\/code> 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\u2019s explanation of error 550 5.6.11<\/a>.)<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
What We Added to text.email<\/h2>\n\n\n\n
Our implementation covers the complete chunked-message transaction, including the boundaries and failure cases that matter when real mail servers communicate:<\/p>\n\n\n\n