Grant Taylor wrote: >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.
First of all, here's what Len Sasso wrote: >All our messages must implement TLS 1.2 or higher for >transport level encryption. I don't know why you're questioning Len's expressed *requirement*. And (don't worry, Len!) it's a very, very reasonable requirement in the year 2020 and beyond. For that matter it was a reasonable requirement 20+ years ago, too. Then there's this fact, which Lionel Dyck kindly pointed out: >CSSMTP is a send only SMTP service - it does not receive anything. Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at least as far as the next hop. CSSMTP alone doesn't provide a return mailbox. According to Google's latest Transparency Report, available here: https://transparencyreport.google.com/safer-email/overview?hl=en 93% of outgoing e-mail from Google and 94% of incoming e-mail to Google rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail services are heavily consumer-oriented ("How is piano practice going?"), and well over 90% of it is encrypted in flight. Len Sasso is dealing with an enterprise system, presumably. Maybe my cousin's medical insurance claim acknowledgment is being e-mailed, or maybe your loan application update is being e-mailed out to you. Does anyone seriously want to question Len's requirement? Or would it be at least as appropriate to question why you haven't enabled encryption for your SMTP and other network traffic, if you haven't? It's very frustrating to me when even basic security precautions and practices are questioned like this. Get it turned on, please! It's quick, easy, and no additional charge. And have a look at the z/OS Encryption Readiness Tool ("zERT"), included with z/OS at no additional charge, to get visibility on where you still have gaps. >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. That's an available configuration choice, that's correct, and that's exactly what *should* happen in myriad real world scenarios to avoid a potential or actual security breach. >Do you really want to have someone perform regular postmaster duties on >z/OS? As Lionel patiently explained, this is about whether Len Sasso's requirement is satisfied, to encrypt e-mail traffic to the next hop. There are no postperson duties here, not with CSSMTP. These are basic network security duties, prudently practiced and respected for decades now. ....But (hypothetically, off on your tangent) why not? It's an IMAP mailbox the postperson(s) monitor, presumably. The postperson probably isn't either configuring and administering a Kubernetes cluster or navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can be, with other software), what's the problem? I'm a little confused here. Isn't this IBM-MAIN? Is there something you wouldn't or don't like about providing more and more useful user services from z/OS? >It might be better to send the email to another exissting corporate >SMTP server where someone is already handling the postmaster duties. Yes, there's something else besides CSSMTP. OK, backing off that tangent.... >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. It is if you configure AT-TLS to require it, which is par for the course really. >Both the sending end (CSSMTP) and the receiving end (remote SMTP server) >need to support encryption. Yes, and as you can see from Google's Transparency Report TLS isn't a rare or exotic thing. (What year is this?) >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. >}:-) Not merely "entertaining." It's one perfectly reasonable, prudent security measure to make spoofing more difficult. >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. Words fail me here. >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. I agree it would be great to encrypt the e-mail body *also*, if possible. Two popular ways are PGP and S/MIME. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
