As mentioned, the SMTP protocol only allows for 1000 bytes of data per line. The author also mentions that they are sending html emails, which ignore line breaks.

So a message intended to be sent by an SMTP client:

DATA

Hello customer,<br>[978 characters] 27.00

Was erroneously formated into:

DATA

Hello customer,<br>[978 characters] 27

.00

.

The period after 27 will be removed. And this is how the html will be rendered.

Hello customer,

[Lots of text] 2700

but html does not ignore line breaks. when part of body text, a run of whitespace (including newline) becomes a single whitespace when rendered.

so splitting 27.00 on the . becomes 27 00, because the CRLF is significant to the client.

you would want to split at whitespace, not at any other character -- unless you had a 999+ string of non-whitespace of course.

perhaps the author didn't know or didn't realize or thought it insignificant to his point that in addition there was a quoted-printable encoding, in which case i believe the trailing/mandatory CRLF can be made non significant for client rendering. personally i still would have split on actual whitespace. (well, i wouldn't have written an smtp client in the first place.)

Hmmmm, html doesn't ignore line breaks, it just treats them as any other whitespace, where a consecutive sequence is folded into a single space. 27 00 would still be quite confusing, of course

I think the space character in the comment above is representing a new line on the wire.

Yep, I didn't add enough newlines. Fixed

From TFA it is stated that they were doing the split of lines because of the "1000 octet" maximum line length requirement of the SMTP protocol.

And, they also state that the period disappeared because it was placed at the start of the next line when the split occurred.

From which one can deduce that they were doing the most basic "split" possible, splitting at the exact 1000 octet point, i.e. something like:

   if (length(line)>1000) then:
     line1=string_range(line,0,999)
     line2=string_range(line,1000,end)
   fi

And if the period in 27.00 ended up exactly at offset 1000 in "line" then it got 'split' into line 2 as the first character of line2.

It would split at 998 characters, since each line must end with CRLF.

I do not understand what you are asking. "$27.00" is a standard expense format.

I think GP was was using the phrase "auto split ... across [character]" in reference to characters that can cause line breaks for "word wrap" purposes in page layouts. For example, a normal space is a character that causes line breaks, but a non-breaking space (nbsp) is not. A hyphen, a tab, a zero-width space (zwsp), and several other characters are also generally used for line breaking. I think GP is saying that the decimal indicator -- the fourth character of "$27.00" -- should not be used for breaking. I think GP assumes that the problematic line breaking in TFA is akin to the type of "word wrap" page layout logic I've just explained; in reality the line breaking in TFA has nothing to do with that, it's simply breaking at 1000 octets (probably for reasons of buffer size, certainly not page layout) regardless of what character is in that position, so this whole thing is moot. GP needs to RTFA!

From the article:

> The maximum total length of a text line including the <CRLF> is 1000

If the period was the 999th character in the line, it would split it to the next line since the maximum line length in SMTP is 1000 characters including CRLF.