Re: This maybe off topic, but could somebody tell me what i am doing wrong?
On 2015-10-21 01:51, John Allen wrote: 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. I have a script that checks for various available updates and the results are written to a file whose contents i redirect to mailx and that works well with multiline text mailx -n -s "Subject" -r f...@example.com t...@example.net <$file I don't recall why i chose this approach but it could be that i was having the same issues with pipeing to mailx Regards Christian thanks everyone John A
Re: This maybe off topic, but could somebody tell me what i am doing wrong?
That is in fact what is installed. Mail and mailx are symlinks to heirloom-mailx.
Solved: This maybe off topic, but could somebody tell me what i am doing wrong?
Switched to sendmail, problems seem to have been solved. THNX
Re: Solved: This maybe off topic, but could somebody tell me what i am doing wrong?
On October 20, 2015 1:17:46 PM John Allenwrote: Switched to sendmail, problems seem to have been solved. THNX are you in case sending the google lotto numbers so ?
Re: This maybe off topic, but could somebody tell me what i am doing wrong?
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
Re: Solved: This maybe off topic, but could somebody tell me what i am doing wrong?
No, I switched from sing heirloom-mail which I believe is a cli MUA to Postfix sendmail. On 2015-10-20 9:33 AM, Wietse Venema wrote: John Allen: Switched to sendmail, problems seem to have been solved. Please clarify: you switched MTA alternatives? Wietse
Re: This maybe off topic, but could somebody tell me what i am doing wrong?
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
Re: Solved: This maybe off topic, but could somebody tell me what i am doing wrong?
John Allen: > Switched to sendmail, problems seem to have been solved. Please clarify: you switched MTA alternatives? Wietse
This maybe off topic, but could somebody tell me what i am doing wrong?
We want to send alerts to our admin staff from some of our remote servers. All the servers are Debian based and supply, smtp, imaps, file sharing (webdav), calendar and address book capabilities. To send the alerts we have tried email and sms messaging. eMail works but can be slow depending upon the number and quailiy of hops needed to get from the server to the admin. We had thought of of simply using a cell phone modem for each server. However cellular service at some of the locations is unreliable (too far north). To get round this we are thinking of using the email to SMS services offered by our telcos. We think SMS might be "faster" and more reliable as all network traffic passes through out telcos/ISPs centres fairly soon after leaving us. So, why doesn't this work echo "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r r...@example.com 4165551...@txt.bell.ca If I run the above I get a test message with the subject and sender correct, but the message arrives with "this message was sent with attachments which were lost". If I send same data using a thunderbird, outlook ... it works perfectly. Looking in the various logs I cannot see any difference between the two message. Postfix seems to behave in exactly the same way all cases. Help! JohnA
Re: This maybe off topic, but could somebody tell me what i am doing wrong?
That should say echo -e "message text \r" | Sorry about that
Re: This maybe off topic, but could somebody tell me what i am doing wrong?
Am 20. Oktober 2015 02:58:43 MESZ, schrieb John Allen: >That should say echo -e "message text \r" | >Sorry about that I'd recommend you install the package heirloom-mailx, it's much more flexible in what you can do with it. Regards Christian