On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis wrote:
>
> Stephen and Kenneth,
>
> Thank you very much for your help.
>
> I tried 'MAILRC=/dev/null' which I put in /etc/mail.rc as
>
> 'set MAILRC=/dev/null'
>
>
No that is meant to be a shell environment variable so that it does not try
to r
On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis wrote:
>
> Stephen and Kenneth,
>
> Thank you very much for your help.
>
> I tried 'MAILRC=/dev/nul' which I put in /etc/mail.rc as
>
> 'set MAILRC=/dev/null'
>
>
No that is meant to be a shell environment variable so that it does not try
to read /etc
Stephen and Kenneth,
Thank you very much for your help.
I tried 'MAILRC=/dev/nul' which I put in /etc/mail.rc as
'set MAILRC=/dev/null'
But I did not identify that this changed any behavior.
The link below was very helpful Stephen thank you for your kindness in digging
this out for
me.
http
--On Friday, September 04, 2020 3:58 PM -0500 "Gregory P. Ennis"
wrote:
On Centos 7 the headers contain 'Content-Transfer-Encoding: base64' and
when the client gets the e-mail they are unable to open it up.
That sounds like a broken client that needs to be updated. What kind of
client?
On Fri, 4 Sep 2020 at 16:00, Gregory P. Ennis wrote:
> Everyone,
>
> I have just upgraded a Centos 5 server to a Centos 7 server and am
> having difficulty with a change of behavior of mailx with the use of a
> command line of :
>
> mail -s 'This is the subject' u...@domain.com < text_file.txt
>
Everyone,
I have just upgraded a Centos 5 server to a Centos 7 server and am
having difficulty with a change of behavior of mailx with the use of a
command line of :
mail -s 'This is the subject' u...@domain.com < text_file.txt
On Centos 5 when mailx was used by a program started by a cron job w
6 matches
Mail list logo
