Right, David.

I know that there are still some bugs to fight and to get rid of. However we should honor the efforts to make a product more secure. And we have to tell development if they create a solution which does not fit to the market.

(btw 96 hours a too long in our business world - I use always 24 hours)

Dietmar,

my point is NOT less security, but functionality first. Have you read what wrote Massimo about the 420 error ? User should get immediately information, that there is no go. Instead is GWIA wrongly trying 96 hours to convince "bad guy" on other end to improve security. There is no one who is listening. 

If there is only one, which isn´t playing right, you can make consultancy, but not with 20 or 30 of it. 

This isn´t solution, but only workaround. 

No, I do not agree David.

Security is important. If you can live with less security then you can change your GWIA options. It's your world and your responsibility.

This TID delivers an option if the original setting does not fit. And because you know the product you searched for a solution and found a solution - that is consultancy - outside of the "next button" community.

Hi,

I see that GroupWise development is holier than Caesar’s wife. I upgraded to 18.2 and see what  ? Users started complaining, that they can not send emails, because of this great new super secure feature. 

Internet is full of unpatched / old etc email servers , but users dont care, they need to send emails, very important emails, business emails . 

If you so care about security, why there is no such function to downgrade to SSLv1 AND send email to postmaster , that his system is unsecure ? Or at least GroupWise system admin ?

This is totally wrong ! I bet, that 99 % of admins , which upgrade to 18.2 will use TID 7024361 to make email work again.

When I first upgraded to 18.2 I added --ssloption "ssl_op_allow_tls_v1_1,ssl_op_allow_tlsv1" to my POA configs to support Macs. It was working and didn't think anything more of it.  Tuesday I upgraded my last remaining domain and PO to 2018.2 and much of my environment stopped working. The POAs would fail to connect to the MTAs. Finally I added the switch to my MTAs and the POAs began to work again. I had to update every POA, MTA and GWIA to allow tls1 before mail was working again.

This whole thing would have been avoided if either there was a new Mac client or if the new Web client that's still in development was featured completely enough to replace the 10 year Mac client. 

Not allowing unencrypted at all is a prominently configurable option in GWIA already, so it's up to the admin to decide, there is absolutely no point to override that conscious admin decision from MF side. The admin, if he cares to, *can* himself disallow unencrypted transfer.

On top, it's still totally unrealistic to enforce encryption on public SMTP servers, *WAY* too many legit SMTP servers out there do not (or not properly) support starttls yet, so enforcing it cuts you off from a significant amount of the internet.

Last but not least, the supposedly "conscious" decision is implemented in a broken way, resulting in a pointless deferral and retry of the sent mail, with an error to the sender only days later when the retries have exhausted. *If* this is on purpose, at the very least on failure the GWIA has to give up immediately and send an error report back to it's sender.

That alone warrants a bugzilla entry, and moves this outside the scope of an IDEA.

No. I am quite happy now there is a workaround. It is still very hard to find in the KB though.

Massimo,

Laura turned this over to me.  In checking with engineering, as they are the ones that made the decision, here is what I have gotten back.

We discussed the fact that GWIA does not fallback to unencrypted transfer.  We did not want to ever use TLS 1.0 without the admin explicitly "dumbing down" their system.  The fallback to unencrypted transfer could be argued, but we never recommend allowing unencrypted.

So if you still believe that GWIA should fallback, please enter an enhancement request and let Mike decide if this is a decision he wants to reverse.

Pam

Thanks for the TID Laura, but I'm afraid I'm still unhappy. 

Like the TID says, TLS 1.0 is considered insecure, yet the TID only tells people to how to re-enable an insecure protocol again. But all this still ignores the fact that this is all only necessary, because GWIA does *not* fallback to unencrypted transfer as it should (per it's configuration), but simply fails to send the mail altogether.

So sorry for being insisting, but is there an exiting bug for this? If not, can/would you enter one? Or does Microfocus consider the current Situation not a bug, but properly working code?

Massimo - I'm busy making enquiries but am out of the office for the next 10 days or so.