A crash seems to result in the client connection getting closed still, rather than a NO response.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 18 2016
Jan 6 2016
Dec 23 2015
Dec 18 2015
same reason T903 was re-opened, and not a buffer overrun or any other security-related issue -> there was a check using a variable which had already been bound with a value, so instead of binding the new value it tested for equality and that would fail.
Pet peeve: re-opening old tasks for new unrelated issues.
Dec 17 2015
Fails on larger numbers of folders.
A workaround configuration that aligns the behaviour of listeners with the behaviour of imap_servers may look as follows, splitting the backend configuration in to one imap_server with { tls, starttls } and one with { tls, true }:
Closed in favour of T928.
Closed in favour of T928.
EDIT: Not the comment I wanted here.
No task description.
No task description.
No task description. Please clarify and reopen if necessary.
Using a { port, 143 }, { tls, starttls } backend does present the client with the necessary capabilities and allows the client to use STARTTLS.
In further troubleshooting, of course this happens while the frontend is on a STARTTLS port, but the backend is on an implicit SSL port -- the capabilities presented to the client match those of the server w/ implicit SSL.
Dec 16 2015
Not sure what commit(s) were related to this ticket for it to have been allowed to move to the Review column, but rG93aef46dc20861092df417703405545e1e0f76b8 with rEIc50001375e81662cae40914dcae9745273765f7b does not present STARTTLS LOGINDISABLED to the client;
Dec 11 2015
Dec 10 2015
Dec 9 2015
That's actually the point of the tls=starttls backend option.
Dec 8 2015
Dec 6 2015
Dec 3 2015
Dec 2 2015
Nov 30 2015
This was caused by something entirely different, and no longer occurs.