I did a few test today.
The results seem to show that its not the -e option in echo that changes
things.
If I leave the -e parameter in place, but do not insert any escaped
characters in the message - things works as I had expected and the
message is sent "correctly".
If on the other hand I insert an escaped character into the message I
get the error "This message has attachments which were lost".
Removing the -e option solves the problem in either case.
I have not looked at the code, so I am guessing, but it seems that
mail/mailx hadle a continuous block of text differently to a multi-line
block. I am not competent to decide if the as it should be or not.
thanks everyone
John A
On 2015-10-20 10:07 AM, Christian Kivalo wrote:
On 2015-10-20 12:38, John Allen wrote:
That is in fact what is installed. Mail and mailx are symlinks to
heirloom-mailx.
True, symlinked to the same binary.
Just tried your initial command. The resulting email has the text
"message text" in the body when run as
echo "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r
f...@example.com t...@example.net
but i get the same error as you when i run the command
echo -e "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r
f...@example.com t...@example.net
mailx seems to base64 encode the message text because of the \r?
The difference between these two invocations in mail headers is:
echo without -e
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
echo with -e
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
regards
christian
