emerge output ends up as attachment.bin when sent with nail / Heirloom mailx

I really like the command line mailer Heirloom mailx (formerly nail), and now there is even a current version in portage again (still under the name mail-client/nail, but that doesn’t matter), so that’s even better. I use it on all servers, since it’s just convenient – it can handle attached files, UTF-8 etc. without any problems.

But there was one problem that bothered me for months already: It involved my check_updates.sh script, which basically just calls /usr/bin/emerge -upvDN --nospinner world for the host and all virtual servers, and then sends the output to me.

The problem: emerge’s output always ended up as ‘attachment.bin’, attached to the (otherwise empty) mail, although I piped it into mail -s "Updates for $DATE" root where it should come out as the mail body. I knew that Heirloom mailx does that, as soon as it doesn’t “like” one of the characters in the input, but I couldn’t think of a reason why it would do that with emerge’s supposedly plain-ASCII output.

Today I had enough of it, and fired up hexdump to investigate said ‘attachment.bin’, using the following command:
hexdump -e '1/1 "%03d \n"' attachment.bin | sort -u
It outputs the unique decimal values of any byte occurring in ‘attachment.bin’ as a sorted list. I expected to find something above 127 – but the highest occurring value was 122 (“z”). I then checked the top part of the list, and to my surprise, found 008 (backspace) there. After removing those by piping the output through tr -d '\010' (8_dec = 10_oct, and tr needs octal values), Heirloom mailx no longer put the text into ‘attachment.bin’. It now appears in the mail’s body, where it belongs.

By the way, those backspaces (when interpreted) change
Calculating dependencies ... done!
to
Calculating dependencies... done!
… so removing them is not a big loss. I’d like to know though, why they are there in the first place, even though the output doesn’t go to a TTY.