specify SMTP relay server in mutt

Fri Jul 18 11:09:12 UTC 2014

Found an RHEL 6.3 server to test out the mailx that supports -S :

# mailx -s "rh1 via smtp1" -a /tmp/tst.tar.gz  -S "smtp=172.20.1.92"
recipient at gmail.com < /tmp/cis/group.tmp

smtp-server: 421 4.7.0 mailrelay2.z-cloud.gov.au closing connection
"/root/dead.letter" 87/2184
. . . message not sent.

What caused the above dead letter?

On that SMTP server 172.20.1.92, I certainly could send emails out using
mutt &
received them (without specifying the relay server) & I understand quite a
number of
current tenants are already successfully sending emails out via this SMTP
server.

On Fri, Jul 18, 2014 at 10:32 AM, Harris, Don <don.harris at unf.edu> wrote:

>
>
> On 7/17/14 11:53 AM, "Sunhux G" <sunhux at gmail.com> wrote:
>
> >To be sure I get this right, the bundled mailx in RHEL6.x support the
> >option
> >     -S "smtp=172.20.1.92"  ?  <== did I get this syntax right?
>
> Correct, the mailx with RHEL6 supports specifying a remote smtp server as
> shown. If in doubt, read the man page and try it on a test system.
>
> >
> >Do you have mailx from EPEL installed in your RHEL & does it run any
> >vulnerable services?  We have regular VA scans so this might be one
> >consideration when I raise Change Requests to install it.
>
> Mailx is called "nail² in the EPEL RHEL5 repo. nail is simply a
> program that runs when you execute it from the command line or script.
> There are no daemons that run in the background.
>
> I don't know what your VA (vulnerability assessment?) scans entail, but if
> they're scanning from the network, they'll never see it because it isn't
> running and doesn't listen on any network ports. If they¹re scanning the
> file system, it¹s just another package that needs to be kept up to date
> like any other package. By all means, talk to your security/audit team
> about it.
>
> >
> >Heard of 'Expect' & TCL scripts but I'm quite handicapped with them.
> >A few  years ago, I saw in one RHEL 4.x a Perl script that send
> >email (without using any tools like mutt/mailx) so if anyone happen
> > to have a copy to share, will save me the hassle of raising Change
> >Requests as Perl interpreter is present by default in RHEL 5.x and
> >putting in a Perl script doesn't need Change Requests.
> >
> >We have mostly RHEL 5.x & only 20 odd RHEL 6.x.
> >
> >My purpose was to email out outputs of 'last', 'lastlog' & 'getent'
> >on fortnight basis as part of user accounts re-certification audit.
>
> A super simple shell script called from cron would do what you need. Just
> test it from the shell first to get the command straight. For example, to
> get the output mailed to you without using a temp file, just pipe the
> command output to mailx like so:
> ‹‹
> #!/bin/sh
> last | mailx -s²last output from `hostname` on `date`² -S
> ³smtp=172.20.1.92² your.email at your.domain
>
> lastlog | mailx -s²lastlog output from `hostname` on `date`² -S
> ³smtp=172.20.1.92² your.email at your.domain
>
> getent passwd | mailx -s²getent output from `hostname` on `date`² -S
> ³smtp=172.20.1.92² your.email at your.domain
>
> ‹‹
>
> Again, this would work out-of-the-box with the mailx package provided in
> RHEL6. For RHEL5, you¹ll need to get the ³nail" package from somewhere
> else. I use and recommend the EPEL project repo for this kind of extra
> package because it is run by Red Hat within the Fedora project. Lots of
> supporting reasons here: https://fedoraproject.org/wiki/About_EPEL
>
> Good luck!
>
> Don
>
> >
> >
> >Thanks
> >SH
> >
> >
> >On Thu, Jul 17, 2014 at 9:16 PM, Harris, Don <don.harris at unf.edu> wrote:
> >
> >> Oops, I see now that the mailx on RHEL5 and RHEL6 and very different
> >> beasts.
> >>
> >> RHEL5: mailx-8.1.1-44.2.2
> >> RHEL6: mailx-12.4-7.el6.x86_64
> >>http://heirloom.sourceforge.net/mailx.html
> >>
> >> The legacy mailx on RHEL5 doesn't support all those options. If it's
> >> acceptable in your environment, you can get the newer "Heirloom" mailx
> >> from the EPEL repository. Note that it's the "nail" package on EPEL. See
> >> https://fedoraproject.org/wiki/EPEL
> >>
> >> HTH,
> >> Don
> >>
> >> On 7/17/14 7:52 AM, "Sunhux G" <sunhux at gmail.com> wrote:
> >>
> >> >Have to remove both -a & -S in order not to get the syntax
> >> >error but the emails never arrive:
> >> >(I'm able to 'telnet 172.20.1.92 25' from the server that mailx is
> >>issued
> >> >from)
> >> >
> >> ># mailx -s "test5" -u root  "smtp=172.20.1.92" recipient at xxx.com <
> >> >/tmp/cis/group.tmp
> >> >    Or
> >> ># mailx -s "test5" -u root "smtp=172.20.1.92:25" recipient at xxx.com <
> >> >/tmp/cis/group.tmp
> >> >
> >> >
> >> >If I issue just the command below from the sendmail relay
> >> >server itself (without the -S & without "smtp=IP_of_SMTP"),
> >> >the emails arrive:
> >> >
> >> > mailx -s "from SMTP2 server" external_recipient at xxx.com <
> /tmp/tst.dat
> >> >
> >> >I browsed thru the man pages for mailx : can't
> >> >locate a -S or "smtp=a.b.c.d" option.  Did I miss
> >> >something?
> >> >
> >> >
> >> >
> >> >On Thu, Jul 17, 2014 at 7:37 PM, Sunhux G <sunhux at gmail.com> wrote:
> >> >
> >> >>
> >> >> What Harris gave with mailx is probably what I'm looking for,
> >> >> just that I can't get the syntax right with -a (or even if I leave
> >> >> out the -a option) :
> >> >>
> >> >> # mailx -s "test" -a /tmp/tst.tar.gz -S "smtp=172.20.1.92"
> >> >> recipient at xxx.com < /tmp/cis/group.tmp
> >> >>     Or (without the -u )
> >> >> # mailx -s "test" -a /tmp/tst.tar.gz -u whitelistid at xxx.com -S
> >> >> "smtp=172.20.1.92" recipient at xxx.com < /tmp/cis/group.tmp
> >> >> mailx: invalid option -- a
> >> >> Usage: mail [-iInv] [-s subject] [-c cc-addr] [-b bcc-addr] to-addr
> >>...
> >> >>             [-- sendmail-options ...]
> >> >>        mail [-iInNv] -f [name]
> >> >>        mail [-iInNv] [-u user]
> >> >> What did I miss?  I've tried with uuencode (referring to some
> >> >> examples on the Net) too but no joy
> >> >>
> >> >>
> >> >> SH
> >> >>
> >> >--
> >> >redhat-list mailing list
> >> >unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> >> >https://www.redhat.com/mailman/listinfo/redhat-list
> >>
> >>
> >> --
> >> redhat-list mailing list
> >> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> >> https://www.redhat.com/mailman/listinfo/redhat-list
> >>
> >--
> >redhat-list mailing list
> >unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> >https://www.redhat.com/mailman/listinfo/redhat-list
>
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>