I compose email as plain text using a fixed-width font. Lately I’ve noticed that messages sent with leading blank spaces on some lines or with multiple blank spaces on a line seem to have their blank spaces removed upon send. So even though I know there are deliberate additional blanks in certain spots when I’m composing, as soon as I hit send those appear to get removed. So the email my recipient gets as well as the email stored in my sent mail folder shows up without those spaces. Blanks at the beginning of the line get removed entirely, multiple blanks within a line get shortened to single blank space.
Is this just me or is this actually a bug/feature? Anybody else see this?
In your Sent folder, do View > Message > Raw Source and see what is happening in detail. Normally there may be two copies, one in plain text and one in html. Recipients will probably see the html unless they have a mail client that lets them choose plain text only.
So the raw source shows the spaces are still there. But Mail is neither displaying them that way (display is not HTML, it’s showing same fixed-width plain text format as I used to compose the email) nor are my recipients seeing them that way.
Then I guess there is no second copy of the text with Content Type: text/html?
If there is no mention of your font name in the code, then recipients email clients will use whatever has been set in their local preferences. But that should not remove spaces.
I do, at least on the receive side for Mail in Monterey. My bank sends bill pay notices in plain text. The columns used to line up, now they don’t. I think this started happening within the last year. Until I read this thread, I thought the bank changed something, but after only a little investigation, I see that it is Mail’s display of the message that is the culprit.
I’d say it’s perhaps just how Mail chooses to display messages to me if I didn’t know it also gets displayed that way to my recipients on their clients. It even shows up missing blanks in their reply quotes (although I guess that in principle could also just be how Mail chooses to display to me).
I don’t even know how that works. How can Mail state that the plain text source sent to others contains spaces, but then their clients (and also their Gmail web interface) does not show any of those spaces?
How can Mail state that the plain text source sent to others contains spaces, but then their clients (and also their Gmail web interface) does not show any of those spaces?
HTML readers often collapse multiple spaces to just one. But if you aren’t sending an html version then this can’t be the reason…
It is not uncommon for text-based readers to collapse whitespace and even remove newlines (using a double-newline sequence to being new paragraphs). This is in order to “pretty print” the text, so it will word-wrap to the window size instead of breaking lines where they appear in the message source.
It’s also not uncommon to remove leading > characters, and instead using them to direct paragraph-indentation logic (e.g. the way HTML blockquote does).
It’s really aggravating when this reformatting messes up tables (and ASCII art), but it was probably intended to make “normal” text paragraphs easier to read.
If there’s no configuration option to enable/disable this behavior, then I think a bug report is in order here.
I don’t see one. There are two “Content-type” headers in the raw source. One in the screen shot earlier (“text/plain”), and another maybe a dozen lines before that one:
FWIW, specified “boundary” is the string that immediately precedes the “text/plain” header. But there is no “text/html” Content-type header in the message.
