One thought on how to "fix" this (based on the reply to the thread you indicated) would be to have that column returned inside a CASE statement where you could do:
CASE WHEN (LEN(column) = 1 and column = '.') THEN '' ELSE REPLACE (column,' .','') END AS column
Problems with that come in IF you need to keep the space period ("% .%") OR need to keep the period only columns ("."). In those cases, I am not sure how you would handle it. My understanding is that this is due to how the email server is reading and handling the message. My understanding of the issue is that the mail server is seeing a period on its own (either with a preceding space or on a line by itself) as a "stop" character. Basically an "end of transmission" character.
I just confirmed this by looking at how to send email via telnet. After sending the proper initial commands, you get presented with:
354 Enter mail, end with "." on a line by itself
So when the mail server sees a . off on it's own, it is thinking it is an end of mail and all data after that is junk data. So to add to that CASE statement above, you would likely also want to tackle CHAR(10) and CHAR(13) (usually together which indicates a new line in Windows, but I think either on their own can be interpreted as a new line... carriage return and newline are what they correspond to).
Another potential solution would be to add a non-printable character before all periods. Something like CHAR(0) (NULL), CHAR(7) (beep), CHAR(9) (tab), etc. Basically, look for all cases where you have a period and put a non-printable character before that the mail server MIGHT be happy with and not think it is an end of message.
References for the telnet thing I found - https://tecadmin.net/ways-to-send-email-from-linux-command-line/#:~:text=5%20Ways%20to%20Send%20Email%20From%20Linux%20Command,POP%2FIMAP%20servers.%20...%204%205.%20Using%20%27telnet%27%20Command