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.
## Example Configuration
In the following example configuration, the backend is configured to use implicit SSL (the most secure), and two `listeners` provide clients with a port 143 IMAP server reverse proxy (expected to function only with `STARTTLS`, as per the outlined scenarios) and a port 993 IMAP server reverse proxy (expected to function only with implicit SSL, as per the outlined scenarios).
```
[
{
kolab_guam, [
{
imap_servers, [
{
default, [
{ host, "192.168.56.101" },
{ port, 993 },
{ tls, true }
]
}
]
},
{
listeners, [
{
imap, [
{ port, 143 },
{ imap_server, default },
{
rules, [
{ filter_groupware, [] }
]
},
{
tls_config, [
{ certfile, "/etc/ssl/sample.pem" }
]
}
]
},
{
imaps, [
{ port, 993 },
{ implicit_tls, true },
{ imap_server, default },
{
rules, [
{ filter_groupware, [] }
]
},
{
tls_config, [
{ certfile, "/etc/ssl/sample.pem" }
]
}
]
}
]
}
]
},
{
lager, [
{
handlers, [
{ lager_console_backend, debug },
{ lager_file_backend, [ { file, "log/error.log"}, { level, error } ] },
{ lager_file_backend, [ { file, "log/console.log"}, { level, info } ] }
]
}
]
},
%% SASL config
{
sasl, [
{ sasl_error_logger, { file, "log/sasl-error.log" } },
{ errlog_type, error },
{ error_logger_mf_dir, "log/sasl" }, % Log directory
{ error_logger_mf_maxbytes, 10485760 }, % 10 MB max file size
{ error_logger_mf_maxfiles, 5 } % 5 files max
]
}
].
```