On 7/22/20 2:17 AM, Timothy Sipples wrote:
CSSMTP. No problem. IBM explains how to set up TLS with CSSMTP here
(current z/OS 2.4 documentation link, subject to change):
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.halz002/cssmtp_tls.htm
That means that z/OS's CSSMTP will be near or on par with other SMTP
servers and related problems securing SMTP traffic. Most of which have
to do with the capabilities of the receiving SMTP server, which is
outside of CSSMTP's control.
It's possible to require TLS 1.2+, exactly as you wish. (Good idea.)
If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
otherwise, and the receiving SMTP system doesn't offer it, the email
will be stuck on z/OS.
Do you really want to have someone perform regular postmaster duties on
z/OS? It might be better to send the email to another exissting
corporate SMTP server where someone is already handling the postmaster
duties. With or without encryption, be it STARTTLS, SMTPS (possibly via
AT-TLS), IPsec transport mode, traditional VPN (IPsec tunnel mode or
something else). The big question is where do you want the email that
doesn't send to reside and who's responsible for managing the queue.
Tony Thigpen wrote:
That's possible, but it means that your e-mail traffic is leaving
your z/OS machine in cleartext.
Maybe, or maybe not. There are other ways to encrypt email leaving
CSSMTP without STARTTLS or SMTPS.
This class of security risks is easily avoidable if you simply enable
TLS on z/OS.
Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
guarantee that the email transmission path to the next SMTP server will
be encrypted.
Both the sending end (CSSMTP) and the receiving end (remote SMTP server)
need to support encryption. Most MTAs can be an encrypted client
without their own TLS certificate. — Though a /client/ TLS certificate
can be entertaining to use in place of username and password for
authenticating the sending system to a relay. }:-)
(N.B. TLS is not "heavy lifting," or at least it hasn't been for
a very, very long time.) There may also be some unnecessary server
complexity in what you've done, adding some inherent fragility.
Perhaps. Though I think there is some benefit to getting email queue
management into the hands of people who's day job is administering email
vs people who's day job is administering the mainframe, which quite
likely is considerably more than just email. ;-)
To be clear (pun intended), there are still one or more e-mail servers
in the transmission path, of course.
It's possible, but difficult to get the SMTP server count down to one,
the receiving system. But this requires the sending application to be
initiating outbound SMTP. Much more common is to have two SMTP servers,
the one the application uses to send and the one that receives it on the
other end. Depending on how things are done, this second path could be
0, 1, or 2 SMTP transactions, each with or without encryption which may
be inside or outside of SMTP.
This is about encrypting the traffic, preferably with TLS certificate
authentication, as early as possible in the path.
That statement sounds like it's trying to put a check mark in a
checkbox. If the task at hand is to secure email, there are many ways
to comply with the spirit -or- have acceptable risk between the
mainframe and an SMTP server over a secure LAN in a secure data center.
If you really want to adhere to the spirit, the email body contents
should be encrypted. So that it doesn't matter nearly as much if the
SMTP transmission path is encrypted or not. But that's another kettle
of fish.
--
Grant. . . .
unix || die
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
