Grant Taylor asks: >What happens to email if CSSMTP (AT-TLS) is configured >to *require* encryption and the receiving system doesn't >support encryption?
Fundamentally the same thing(s) that happen when the network connection is down or too slow (times out), for whatever reasons. Network encryption is part and parcel of the network path. This class of failures must already be catered for. In this case, Len Sasso's organization is mandating TLS 1.2+, and I agree with Shmuel Metz who wrote: >If management has decreed that all SMTP traffic be encrypted, >then barring a configuration error the relay will accept >encrypted traffic. Moreover, it's entirely possible that your attitude would only increase relay administrators' burdens, the people who currently have to manage, support, monitor, and audit the e-mail traffic from the one and only system still transmitting over an unencrypted connection, a connection modality they'd very much like to retire as quickly as possible. You know, that "old, obsolete mainframe" that you're actively arguing should actually be as old and obsolete as you can possibly force it to be. (TLS is *really* not new.) Or it's entirely possible that the relay administrators aren't inclined or equipped to provide even mediocre service levels for unencrypted connections, or even that there's a lone dedicated relay gathering dust in a wiring closet somewhere to support this one unencrypted connection, a relay that nobody left in the organization even understands or really knows about, that isn't backed up or DR protected, that still runs on a 10 Mbps Ethernet segment that miraculously hasn't been disconnected yet. Hence the unencrypted connection is MORE prone to failure, not less. All very possible, even predictable and likely. And I haven't even gotten to the regulatory issues and penalties. Conceivably you could also reduce or eliminate your personal security authentication failure planning and handling (hopefully automated) responsibilities if you effectively disable your SAF security provider, such as RACF. Then those few pesky authentication and authorization rejections wouldn't occur, and everyone could just go to the pub and stay there (or whatever). That's the logical consequence of your argument, isn't it? I don't think you've got a strong argument. Sorry to be blunt here, but I feel compelled to offer my personal view (as always). My colleagues (and I mean that word expansively, in and out of IBM) work really hard to deliver and support truly cutting edge capabilities, including downright amazing security capabilities, in/for this unique and indispensable platform. And this community, overall, often works really hard to put these capabilities into practice, in many cases literally to keep civilization functioning. Then there are a few people who manage a few of these systems, and...well, let's all strive to do better, OK? [Why am I expecting a minor Twitter storm now? :-)] - - - - - - - - - - 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
