On 7/23/20 1:24 AM, Seymour J Metz wrote:
But what, someone may ask, if the realy connects to a box that doesn't
support TLS 1.2? The same thing as if the traffic from CSSMTP were
unencrypted, and not the concern of the z/OS staff unless the relay
is also running on z/OS.
What happens to email if CSSMTP (AT-TLS) is configured to *require*
encryption and the receiving system doesn't support encryption?
I presume that CSSMTP will fail to send the email b/c of the lack of
encryption.
What happens to these unsent emails?
Does an error get sent back to the sending application?
Do the unsent messages pile up in a spool somewhere?
Even at ~90% support for encryption, that's one in ten emails that can't
be sent via encrypted channels. What happens to that 10% that can't be
sent with encryption? Also, I don't believe the ~90% figure. I believe
it to be somewhere between 60% and 70% and that there is a geographic
influence to the number.
I agree that requiring encryption is perfectly reasonable. I think that
requiring TLS 1.2 is a laudable goal.
But I also think it would be negligent to fail to have a plan for email
that can't be sent via encrypted channels.
What happens to the email that CSSMTP (AT-TLS) wants to send if the
receiving system has an expired certificate and thus fails validation?
This is a fairly common short lived oops.
Also, I was not questioning the merit of TLS. I was simply inquiring if
the requirement was for encryption, which can be accomplished multiple
ways, or if it was for TLS specifically.
--
Grant. . . .
unix || die
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
