Bugzilla

> That was one area hard to get one's head around, which direction to go... Through an error manually, and tell the thread to die, or to return error conditions and let errors.. bubble through to native termination on error.

Before looking at this I probably need to understand what the IMAP clientid thing actually does or is supposed to do. From my observation with the cityemail.com account I don't see any effect. I first connected with the patched version of tb that sent the clientid (the "coffee" string in my case). I then connected with a release version and it worked OK even with no clientid sent. Then on the tb version having the patch that sends clientid, I modified the string sent so it was "coffee-gds" and that worked too, no complaints and CLIENTID command responded with OK.

So maybe the reason for the permissive behavior is because the server is set up permissive. Assuming that's what it is, and with a strict server, how would it behave with a bad or missing clientid command?

1. Server remembers the 1st client ID string it receives for an account.
2. Each time a client connects via tls it expects to see same client ID again.
2.1 If server sees it, authentication occurs and all is OK for that mailbox
2.2 If server sees a different client ID, what does it do? I would think it would fail the authentication? Or maybe it allows authentication but sends a email to one or more addresses warning that a different Id has been used for access.
2.3 If it sees no client ID (CLIENTID not supported by client) does it still allow authentication? Or maybe also just sends an email warning(s)?

So if the ClientID() function fails and this results in no string sent or maybe the wrong string, it may not matter if this causes the server to fail authentication. Or it may not matter if it allows authentication but sends a warning email that someone accessed the account without a client ID. 

I went back and re-read the draft imap clientid spec and it seem like it really doesn't specifically answer my questions. So I assume that the behavior would be server specific. Is or should there be a place where a user can configure the permissiveness of strictness of the server? I didn't see anything about clientid on your webmail.

(Note: I haven't yet applied the smtp patch or even looked at it yet.)

> That was one area hard to get one's head around, which direction to go... Through an error manually, and tell the thread to die, or to return error conditions and let errors.. bubble through to native termination on error.

Before looking at this I probably need to understand what the IMAP clientid thing actually does or is supposed to do. From my observation with the cityemail.com account I don't see any effect. I first connected with the patched version of tb that sent the clientid (the "coffee" string in my case). I then connected with a release version and it worked OK even with no clientid sent. Then on the tb version having the patch that sends clientid, I modified the string sent so it was "coffee-gds" and that worked too, no complaints and CLIENTID command responded with OK.

So maybe the reason for the permissive behavior is because the server is set up permissive. Assuming that's what it is, and with a strict server, how would it behave with a bad or missing clientid command?

1. Server remembers the 1st client ID string it receives for an account.
2. Each time a client connects via tls it expects to see same client ID again.
2.1 If server sees it, authentication occurs and all is OK for that mailbox
2.2 If server sees a different client ID, what does it do? I would think it would fail the authentication? Or maybe it allows authentication but sends a email to one or more addresses warning that a different Id has been used for access.
2.3 If it sees no client ID (CLIENTID not supported by client) does it still allow authentication? Or maybe also just sends an email warning(s)?

So if the ClientID() function fails and this results in no string sent or maybe the wrong string, it may not matter if this causes the server to fail authentication. Or it may not matter if it allows authentication but sends a warning email that someone accessed the account without a client ID. 

I went back and re-read the draft imap clientid spec and it seem like it really doesn't specifically answer my questions. So I assume that the behavior would be server specific. Is or should there be a place where a user can configure the permissiveness or strictness of the server? I didn't see anything about clientid on your webmail.

(Note: I haven't yet applied the smtp patch or even looked at it yet.)