Bugzilla

(In reply to Jorg K (GMT+2) from comment #89)
> Comment on attachment 9059903 [details] [diff] [review]
> imap-patch-clientid-thunderbird-april-22-2019.diff
> 
> Thanks for updating the comment. Gene, can you please put your seal of
> approval onto this.
> 
> > That string is what is presented as the CLIENTID token.
> > Coincidence that Thunderbird already called it ClientID.
> 
> I'm afraid you will have to educate the reviewer here and give him/me a
> short summary about this "client ID" stuff, unless you want me to study the
> RFCs linked in comment #0. All I can see is that you're using pref
> `toolkit.telemetry.cachedClientID` and that seems to uniquely identify the
> profile you're using.

Jorg, Not sure if you are asking me or Dan but here's my understanding of clientid based on reading the imap spec and emails from Michael and Dan:

For imap, you have to set up with SSL/TLS or STARTTLS. Tb makes a tcp/ip connection to the appropriate server port (993 typically for TLS, 143 for STARTTLS) and tb and the server then create a secure connection using TLS. If STARTTLS used, tb sends a STARTTLS imap command to change over to TLS. The server then sends an unsolicited (untagged) CAPABILITY response with capability CLIENTID advertised.
```
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE CLIENTID AUTH=PLAIN] MagicMail ready.
```
When TB see the CLIENTID capability and it verifies the connection type is tls or starttls, it then sends the clientid command:
```
tb: abc CLIENTID TB-UUID <toolkit.telemetry.cachedClientID>
sr: abc OK Recognized a valid CLIENTID command, used for authentication methods
```
Without clientid seen in capabilities, tb would just go ahead and do its normal authentication after the capability response is received. But if the server supports clientid, authentication will fail unless tb first sends the clientid string. So if clientid not sent first, authentication will fail like this:
```
tb: 123 login gene@mail.com mycrypticpassword
sr: 123 NO [AUTHENTICATIONFAILED] Authentication failed.
```
So after clientid is send, authentication can occur
```
tb: def login gene@mail.com mycrypticpassword
sr: def OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE QUOTA] Logged in
```
The way I understand it is that if an unacceptable clientid value is sent, the server will still send an OK response. (It will send BAD only if the syntax is wrong due to tb coding error; never sends a NO.)  A failure will occur when the client tries to authenticate and the clientid sent was wrong. There will be no indication that the problem is due to an unacceptable clientid string and this is by design.

An idea is that at the server's webmail the tb user can configure which CLIENTIDs are valid so if an unauthorized user gets your password, they won't know your clientid so their login will fail. You can also optionally set the server to send email notification to you of unauthorized access attempts from devices with unregistered clientIDs.

Note: I haven't personally verified that```toolkit.telemetry.cachedClientID``` is really a UUID for every TB instance and profile, so the above discussion **assumes** it is.

(In reply to Jorg K (GMT+2) from comment #89)
> Comment on attachment 9059903 [details] [diff] [review]
> imap-patch-clientid-thunderbird-april-22-2019.diff
> 
> Thanks for updating the comment. Gene, can you please put your seal of
> approval onto this.
> 
> > That string is what is presented as the CLIENTID token.
> > Coincidence that Thunderbird already called it ClientID.
> 
> I'm afraid you will have to educate the reviewer here and give him/me a
> short summary about this "client ID" stuff, unless you want me to study the
> RFCs linked in comment #0. All I can see is that you're using pref
> `toolkit.telemetry.cachedClientID` and that seems to uniquely identify the
> profile you're using.

Jorg, Not sure if you are asking me or Dan but here's my understanding of clientid based on reading the imap spec and emails from Michael and Dan:

For imap, you have to set up with SSL/TLS or STARTTLS. Tb makes a tcp/ip connection to the appropriate server port (993 typically for TLS, 143 for STARTTLS) and tb and the server then create a secure connection using TLS. If STARTTLS used, tb sends a STARTTLS imap command to change over to TLS. The server then sends an unsolicited (untagged) CAPABILITY response with capability CLIENTID advertised.
```
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE CLIENTID AUTH=PLAIN] MagicMail ready.
```
When TB see the CLIENTID capability and it verifies the connection type is tls or starttls, it then sends the clientid command:
```
tb: abc CLIENTID TB-UUID <toolkit.telemetry.cachedClientID>
sr: abc OK Recognized a valid CLIENTID command, used for authentication methods
```
Without clientid seen in capabilities, tb would just go ahead and do its normal authentication after the capability response is received. But if the server supports clientid, authentication will fail unless tb first sends the clientid string. So if clientid not sent first, authentication will fail like this:
```
tb: 123 login gene@mail.com mycrypticpassword
sr: 123 NO [AUTHENTICATIONFAILED] Authentication failed.
```
So after clientid is send, authentication can occur
```
tb: def login gene@mail.com mycrypticpassword
sr: def OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE QUOTA] Logged in
```
The way I understand it is that if an unacceptable clientid value is sent, the server will still send an OK response. (It will send BAD only if the syntax is wrong due to tb coding error; never sends a NO.)  A failure will occur when the client tries to authenticate and the clientid sent was wrong. There will be no indication that the problem is due to an unacceptable clientid string and this is by design.

An idea is that at the server's webmail the tb user can configure which CLIENTIDs are valid so if an unauthorized user gets your password, they won't know your clientid so their login will fail. You can also optionally set the server to send email notification to you of unauthorized access attempts from devices with unregistered clientIDs. But server policy for validating and accepting the clientid sent by the client (tb) is purely server dependent and does not involve tb.

Note: I haven't personally verified that```toolkit.telemetry.cachedClientID``` is really a UUID for every TB instance and profile, so the above discussion **assumes** it is.

(In reply to Jorg K (GMT+2) from comment #89)
> Comment on attachment 9059903 [details] [diff] [review]
> imap-patch-clientid-thunderbird-april-22-2019.diff
> 
> Thanks for updating the comment. Gene, can you please put your seal of
> approval onto this.
> 
> > That string is what is presented as the CLIENTID token.
> > Coincidence that Thunderbird already called it ClientID.
> 
> I'm afraid you will have to educate the reviewer here and give him/me a
> short summary about this "client ID" stuff, unless you want me to study the
> RFCs linked in comment #0. All I can see is that you're using pref
> `toolkit.telemetry.cachedClientID` and that seems to uniquely identify the
> profile you're using.

Jorg, Not sure if you are asking me or Dan but here's my understanding of clientid based on reading the imap spec and emails from Michael and Dan. I suspect you also want a summary of how the SMTP clientid works too. But I will wait to described that until after you understand the imap implementation which is actually simpler.

For imap, you have to set up with SSL/TLS or STARTTLS. Tb makes a tcp/ip connection to the appropriate server port (993 typically for TLS, 143 for STARTTLS) and tb and the server then create a secure connection using TLS. If STARTTLS used, tb sends a STARTTLS imap command to change over to TLS. The server then sends an unsolicited (untagged) CAPABILITY response with capability CLIENTID advertised.
```
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE CLIENTID AUTH=PLAIN] MagicMail ready.
```
When TB sees the CLIENTID capability and it verifies the connection type is tls or starttls, it then sends the clientid command via the now encrypted and secure channel:
```
tb: abc CLIENTID TB-UUID <toolkit.telemetry.cachedClientID>
sr: abc OK Recognized a valid CLIENTID command, used for authentication methods
```
Without clientid seen in capabilities, tb would just go ahead and do its normal authentication after the capability response is received. But if the server supports clientid, authentication will fail unless tb first sends the clientid string. So if clientid is not sent first, authentication will fail like this:
```
tb: 123 login gene@mail.com mycrypticpassword
sr: 123 NO [AUTHENTICATIONFAILED] Authentication failed.
```
So after clientid is sent, authentication can occur
```
tb: def login gene@mail.com mycrypticpassword
sr: def OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE QUOTA] Logged in
```
The way I understand it is that if an unacceptable clientid value is sent, the server will still send an OK response. (It will send BAD only if the syntax is wrong due to tb coding error; clientid does not specify a NO response.)  A failure will occur when the client tries to authenticate and the clientid sent was wrong, so the error will appear to be a bad user ID or password. There will be no indication that the problem is due to an unacceptable clientid string and this is by design.

An idea is that at the server's webmail the tb user can configure which CLIENTIDs are valid so if an unauthorized user gets your password, they won't know your clientid so their login will fail. You can also optionally set the server to send email notification to you of unauthorized access attempts from devices with unregistered clientIDs. But server policy for validating and accepting the clientid sent by the client (tb) is purely server dependent and does not involve tb.

Note: I haven't personally verified that```toolkit.telemetry.cachedClientID``` is really a UUID for every TB instance and profile, so the above discussion **assumes** it is.