Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of the missing period

tjaart.substack.com

Post reply on HN
Print view View original

21–30 of 201 posts

Re: The curious case of the missing period

#21

Post by Aloisius »

pwg wrote: post #14
jiveturkey wrote: post #8

> This meant some customers received emails informing them their new premium was now $2700 instead of $27.00. there's a secondary issue here, why in the world would you auto split a monetary value across a numeric decimal indicator? why would you split lines at all for this use case?

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 (leng…

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

Re: The curious case of the missing period

#24

Post by f33d5173 »

kr0bat wrote: post #18
jiveturkey wrote: post #8

> This meant some customers received emails informing them their new premium was now $2700 instead of $27.00. there's a secondary issue here, why in the world would you auto split a monetary value across a numeric decimal indicator? why would you split lines at all for this use case?

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, [978 characters] 27.00 Was erroneously formated into: DATA Hello customer, [978 characters] 27 .00 . The period after 27 will be removed. And this is how the html will be rendered. Hel…

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

Re: The curious case of the missing period

#25

Post by otterley »

teddyh wrote: post #17

I see two huge bad habits here. The first is the obvious one, as pointed out by many commenters here: Don’t implement standards haphazardly, if you even should do so yourself. Either give the implementations the necessary care and attention, or use a pre-made library. But the other thing is: Don’t vendor your dependencies. Those libraries you use need to be updated regularly and timely, and absolutely not “only as ne…

> Don’t vendor your dependencies.

The alternative seems worse: your own application's stability is now at risk against upstream changes that could break your code. Sure, you might not get a fix immediately, but I'd rather know I'm making a change because I need a fix than introducing instability and additional risk that I don't want to subject myself to. "If it ain't broke, don't fix it."

Re: The curious case of the missing period

#27

Post by hunter2_ »

HeatrayEnjoyer wrote: post #12
jiveturkey wrote: post #8

> This meant some customers received emails informing them their new premium was now $2700 instead of $27.00. there's a secondary issue here, why in the world would you auto split a monetary value across a numeric decimal indicator? why would you split lines at all for this use case?

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!

Re: The curious case of the missing period

#28

Post by jeffbee »

blueflow wrote: post #22
jeffbee wrote: post #16

If a person has never heard of dot stuffing they're never going to believe what other horrors lie within the email space. Header folding, quoting in the local part, ipv6 literals, etc.

Whats the issue with ipv6 literals?

Everything that is normally annoying with IPv6 literals, plus the fact that it's encapsulated as [IPV6:] and the address could take a dumb form such as ::1.2.3.4. But I mentioned it because it might initially seem to a neophyte in this field that the thing to the right of the rightmost @ sign is a name you can pass to your resolver. It might not be.

Re: The curious case of the missing period

#29

Post by kazinator »

jeffbee wrote: post #28
blueflow wrote: post #22

Earlier quoted context omitted.

Whats the issue with ipv6 literals?

Everything that is normally annoying with IPv6 literals, plus the fact that it's encapsulated as [IPV6: ] and the address could take a dumb form such as ::1.2.3.4. But I mentioned it because it might initially seem to a neophyte in this field that the thing to the right of the rightmost @ sign is a name you can pass to your resolver. It might not be.

The IPv6 notation claims : for separating digits. But that's already an established notation for port numbers: 10.1.2.3:456. Oops!

The square brackets allow us to stick a port number on it: [ffff::0123:4567]:6301

Re: The curious case of the missing period

#30

Post by tingletech »

f33d5173 wrote: post #24
kr0bat wrote: post #18

Earlier quoted context omitted.

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, [978 characters] 27.00 Was erroneously formated into: DATA Hello customer, [978 characters] 27 .00 . The period after 27 will be removed. And this is how the html will be rendered. Hel…

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.
Post reply on HN