If zimbraMailMode is set to redirect or https it would be great if there was an option to enable HSTS (HTTP Strict Transport Security) and set the max-age. The simplest solution would be an LDAP attribute like zimbraMailSSLPolicyMaxAge which if missing disables the feature and if set (zero is a valid option) a header with the given value is sent, ie: Strict-Transport-Security: max-age=${zimbraMailSSLPolicyMaxAge}
Current workaround: zmprov mcf +zimbraResponseHeader "Strict-Transport-Security: max-age=31536000"
Malte (or anyone else interested) would you be willing to comment on if you feel there is a need to do something different than simply utilizing zimbraResponseHeader as you mentioned in comment #1? I realize that my not be the most elegant solution, but at the same time it isn't clear that there's a great benefit from doing something more elegant either (e.g. setting the header only upon accessing specific endpoints). Thoughts? Note, we also have bug 98938 not where we're considering having the equivalent of zimbraResponseHeader for the proxy.
You mean apart from the fact that setting zimbraResponseHeaders is broken right now (cf. bug 98495)? :-) Setting the headers manually is definitely doable; if there was a GUI to add headers (is there?).
Marking this as fixed for 8.7 release. The official solution is to use zimbraResponseHeader (broken in 8.5 and 8.6) in a manner similar to comment #1. If desired, a separate bug will be necessary to capture the desire to be able to set zimbraResponseHeader via the Admin [web] Console. (I'm not sure if that was the original intent of this bug or not, sorry if I misinterpreted this) To verify this bug: - ideally we would have QA automation set and check that zimbraResponseHeader gets set and passed appropriately when accessing ZWC. Another option would be to mark this bug as a duplicate of bug 98495 I suppose since that bug was blocking of using zimbraResponseHeader as desired.
(In reply to Phil Pearl from comment #6) > Marking this as fixed for 8.7 release. The official solution is to use > zimbraResponseHeader (broken in 8.5 and 8.6) in a manner similar to comment > #1. > > If desired, a separate bug will be necessary to capture the desire to be > able to set zimbraResponseHeader via the Admin [web] Console. (I'm not sure > if that was the original intent of this bug or not, sorry if I > misinterpreted this) > > To verify this bug: > - ideally we would have QA automation set and check that > zimbraResponseHeader gets set and passed appropriately when accessing ZWC. > > Another option would be to mark this bug as a duplicate of bug 98495 I > suppose since that bug was blocking of using zimbraResponseHeader as desired. Added separate bug 99547 for the above issue and marking this as verified as it working fine from back end.