This ticket supersedes the sagas in T864 and T902.
## Frontend Connections (`listeners`)
Regardless of the configuration of a backend connection, when a client connects to a listener that is not configured to apply implicit SSL, the following capabilities need to be provided (no more, and no less):
```
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS LOGINDISABLED] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3-Kolab-2.5.6-3.1.el6.kolab_14 server ready
```
This will allow a client to upgrade the connection with TLS, by using the `STARTTLS` command, without bypassing the upgrade of the connection.
However, a current initial (i.e. pre-`STARTTLS`) #Guam capability response looks as follows:
```
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES
ANNOTATEMORE ANNOTATE-EXPERIMENT-1 LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE URLAUTH
URLAUTH=BINARY X-NETSCAPE MUPDATE=mupdate://mupdate.mykolab.com/ AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE X-QUOTA=STORAGE
X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE STARTTLS] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3-
Kolab-2.5.6-3.1.el6.kolab_14 server ready
```
This includes some 41 capabilities that are superfluous, but more importantly;
* Includes `AUTH=PLAIN`,
* Includes `AUTH=LOGIN`,
* Includes `SASL-IR`,
* Includes `COMPRESS=DEFLATE`,
* Does **NOT** include `LOGINDISABLED`
Moreover, when the client connects to a listener that is configured to apply implicit SSL, the following capabilities are offered in current #Guam / #EImap:
```
verify error:num=18:self signed certificate
TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES
ANNOTATEMORE ANNOTATE-EXPERIMENT-1 LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE URLAUTH
URLAUTH=BINARY X-NETSCAPE MUPDATE=mupdate://mupdate.mykolab.com/ AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE X-QUOTA=STORAGE
X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE STARTTLS] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3-
Kolab-2.5.6-3.1.el6.kolab_14 server ready
```
Please note the presence of `STARTTLS` on a listener that is configured to apply implicit SSL.
## Backend connections (`imap_servers`)
The #Guam architecture is mistakenly using backend configuration to impose logic on frontend connections (`listeners`) that deserve treatment in their own right.
## Summary
| # | Listener | Port | STARTTLS? | Implicit SSL? | Backend | Port | TLS | Relevant? |
| 1 | imap | 143 | no. | false | imap | 143 | false | no. |
| 2 | imap | 143 | yes. | false | imap | 143 | false | yes. |
| 3 | imap | 143 | yes. | false | imap | 143 | starttls | yes. |
| 4 | imap | 143 | yes. | false | imaps | 993 | true | yes. |
| 5 | imaps | 993 | no. | true | imap | 143 | false | yes. |
| 6 | imaps | 993 | no. | true | imap | 143 | starttls | yes. |
| 7 | imaps | 993 | no. | true | imaps | 993 | true | yes. |
"no." and "yes." are functional requirements, "true", "false" and "starttls" are configuration values or runtime parameters.
# Scenario is invalid and not valuable, on the principle of not offering clients unencrypted connections, period.
# Scenario 2 is valid, providing a TLS termination point. Connection to backend is plaintext and w/o TLS.
# Scenario expects clients to use `STARTTLS`. Scenario should offer clients a correct `STARTTLS` connection upgrade procedure despite configuration or runtime state for backend connections. See also Scenario #4.
# See Scenario #3.
# Scenario 5 is as valid as Scenario 2, for precisely the same reasons. The client does expect **NO** `STARTTLS` among the capabilities presented to it.
# Scenario 6 is as valid as Scenario 3, 4 and 7. The client does expect **NO** `STARTTLS` among the capabilities presented to it, despite the backend configuration perhaps maybe incidentally having been configured to be connected to using a `STARTTLS`-based explicit connection security upgrade procedure.
# Scenario 7 is as valid as Scenario 3, 4 and 6. The client does expect **NO** `STARTTLS` among the capabilities presented to it.