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

11–20 of 201 posts

Re: The curious case of the missing period

#11

Post by blueflow »

quotemstr wrote: post #7
evmar wrote: post #5

> A portion of this code implemented a SMTP client. If I wanted to root cause this, the real problem is right there. Implementing protocols correctly is hard and bugs like in the post are common. A properly implemented SMTP client library, like one you would pull off the shelf, would accept text and encode it properly per the SMTP protocol, regardless of where the periods were in the input. The templating layer shoul…

> Implementing protocols correctly is hard That's why it's a best practice to specify protocols at a very high level (e.g. using cap'n'proto) instead of expecting every random sleep-deprived SDE2 to correctly implement a network exchange in terms of read() and write().

That why you have to read the specs of the protocol you want to implement. Its a matter of engineering rigorousness. Brute-forcing until "it works" doesn't cut it.

Re: The curious case of the missing period

#12

Post by HeatrayEnjoyer »

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.

Re: The curious case of the missing period

#13

Post by Aloisius »

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?

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.

Re: The curious case of the missing period

#14

Post by pwg »

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 (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.

Re: The curious case of the missing period

#17

Post by teddyh »

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 necessary”. If updates lag behind or are avoided entirely, bugs like this can be huge problems even when the upstream code has been fixed, for people who thought that they should update only when they, themselves, see a problem or need.

Re: The curious case of the missing period

#18

Post by kr0bat »

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.

Hello customer,

[Lots of text] 2700

Re: The curious case of the missing period

#19

Post by the_real_tjaart »

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 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.

I agree 100%.

Re: The curious case of the missing period

#20

Post by blueflow »

unilynx wrote: post #15
blueflow wrote: post #2

You can avoid this mess altogether by using the quoted-printable content encoding when generating emails.

How so? Quoted printable doesn't require the dot to be encoded. Maybe you're thinking of base64 encoding?

Doesn't require, but comfortably allows you to do.
Post reply on HN