Bug 1737514 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

From your imap log:
```
SendData: 39 ENABLE UTF8=ACCEPT
CreateNewLineFromSocket: * ENABLED UTF8=ACCEPT
CreateNewLineFromSocket: * OK ENABLE completed
```
According to the "Enable" rfc, https://datatracker.ietf.org/doc/html/rfc5161, the "OK" response above must be tagged. The RFC provides this example on page 3:
```
   In the following example, the client enables CONDSTORE:

      C: a1 ENABLE CONDSTORE
      S: * ENABLED CONDSTORE
      S: a1 OK Conditional Store enabled
```
So the 3rd line from your server appears to be wrong. It should be like this, tagged:
```
CreateNewLineFromSocket:  39 OK ENABLE completed
```
Also, it appears that your server does not list the UTF8=ACCEPT capability. Instead it lists several other UTF8=* capabilities that are now obsolete and have never been supported by TB. So if your server actually doesn't support the UTF8=ACCEPT capability, the attempt to enable it should respond like this (leaving off the untagged ENABLED line):
```
SendData: 39 ENABLE UTF8=ACCEPT
CreateNewLineFromSocket: 39 OK ENABLE completed
```
From your imap log:
```
SendData: 39 ENABLE UTF8=ACCEPT
CreateNewLineFromSocket: * ENABLED UTF8=ACCEPT
CreateNewLineFromSocket: * OK ENABLE completed
```
According to the "Enable" rfc, https://datatracker.ietf.org/doc/html/rfc5161, the "OK" response above must be tagged. The RFC provides this example on page 3:
```
   In the following example, the client enables CONDSTORE:

      C: a1 ENABLE CONDSTORE
      S: * ENABLED CONDSTORE
      S: a1 OK Conditional Store enabled
```
So the 3rd line from your server appears to be wrong. It should be like this, tagged:
```
CreateNewLineFromSocket:  39 OK ENABLE completed
```
Also, it appears that your server does not list the UTF8=ACCEPT capability. Instead it lists several other UTF8=* capabilities that are now obsolete and have never been supported by TB. So if your server actually doesn't support the UTF8=ACCEPT capability, the attempt to enable it should respond like this (leaving off the untagged ENABLED line):
```
SendData: 39 ENABLE UTF8=ACCEPT
CreateNewLineFromSocket: 39 OK ENABLE completed
```
Edit/Addendum:
Here an except from an email exchange with Arnt Gulbrandsen, author of ENABLE rfc referenced above. I had misunderstood how ENABLE works and he corrected me:
```
On Sunday 2 August 2020 22:00:59 CEST, Gene Smith wrote:
> So I think you saying that if I see the ENABLE capability I should just go ahead
 and send ENABLE UTF8=ACCEPT and not worry about checking the capability UTF8=ACCEPT.
 If it fails with NO (or BAD) response then I know the server doesn't support it. If response is
 OK then the server has enabled UTF8=ACCEPT and I'm good to go.

Close, but not quite. You'll get NO or BAD if ENABLE fails. If ENABLE works but 
has no effect, you'll get OK.

What you should do is look for the ENABLE capability, and if you see that,
you send ENABLE UTF8=ACCEPT, and then you look at the ENABLED response.
If the ENABLED response contains UTF8=ACCEPT you're good to go. See the
last three lines of RFC 5161 page 3:

https://tools.ietf.org/html/rfc5161#page-3
```

Back to Bug 1737514 Comment 4