Summary

  • RFC 3676 added DelSp to distinguish a natural space retained at a flowed-text break from the space inserted solely to mark a soft break.
  • The default is no; a sender using the newer break method for scripts where ASCII spaces are rare or absent must signal DelSp=yes, so a receiver removes the marker rather than inserting a character into the reconstructed text.

A line ending in a space can be surprisingly ambiguous. In text/plain; format=flowed, it may be a paragraph continuing below the screen. But the space itself may have been part of the original words—or it may be a marker the mailer added so the next physical line can be joined to this one. RFC 3676, published in 2004, made that distinction explicit with the DelSp parameter. It obsoleted RFC 2646, retaining flowed text while adding a control for how a receiver reconstructs a soft break. (RFC 3676, §§4–4.2.)

The older method could break only where a space already divided words. The sender put CRLF after that existing space. On receipt, the client joined the physical lines but kept the word separator. RFC 3676 says this method SHOULD use DelSp, set to no. That is a preservation rule: the space did not originate as a line-break token, so joining should not erase it.

The newer method solves a different problem. In writing systems where ASCII spaces are uncommon or absent, there may be no natural word gap at which to wrap. The sender can insert a space followed by CRLF—SP CRLF—at the chosen break. In the flowed representation, the trailing space marks continuation; with DelSp=yes, the receiver deletes that one marker when joining the lines. Without the deletion, a display transformation could add a character that was not in the original sequence. RFC 3676 therefore requires DelSp=yes for this insertion technique. The parameter is not a language detector: the sender declares which encoding rule it used. (§§4, 4.1–4.2.)

The defaults matter. If DelSp is missing or its value is unrecognized, the receiver assumes no. DelSp without Format=Flowed is undefined, and receivers SHOULD ignore it outside text/plain; format=flowed. So an absent parameter does not invite a client to guess that a trailing space was synthetic. This conservative default preserves the older interpretation, but it cannot recover the sender's intended strategy if the required metadata was lost.

The two operations can collide with another safeguard. If the sender inserts a break immediately before an existing space, that original space becomes the first character on the next line. Flowed text uses space-stuffing for lines that begin with a space, > or From , so the sender has created extra work simply by choosing the wrong side of the existing separator. RFC 3676 recommends placing the inserted SP CRLF after the pre-existing space instead. This preserves both the old separator and the new break marker as distinct things. (§§4.2, 4.4.)

The scope is deliberately modest: RFC 3676 describes an on-wire text/plain format, not how a local file is stored. Content-transfer encoding is a separate layer. The specification also explains how to prepare flowed content before signing or encryption and how to verify before reflow; that cryptographic order is covered by the separate RFC 2646 commission, not this one. Nor does the standard establish how any named mail client behaved. As Note 65's running-code lens insists, an interoperable rule and observed client behavior are different evidence. The rule says how a conforming pair should preserve text; only versioned implementations and captured messages could show what users actually saw.

Sources

  • RFC 3676, especially §§4.1–4.2 and Appendix A.
  • RFC 2646, the superseded flowed-text specification.
  • RFC 2046, MIME media-type framework.
  • RFC 2045, MIME message-body and transfer-encoding context.
  • Lu Heng, Note 65, disclosed analytical lens, not implementation evidence.