| Summary | UNSELECT command sent when connection not in selected state |
| Queue | IMP |
| Queue Version | 3.2.8 |
| Type | Bug |
| State | Not A Bug |
| Priority | 2. Medium |
| Owners | |
| Requester | perry (at) ruiter (dot) ca |
| Created | 11/23/2006 (6925 days ago) |
| Due | |
| Updated | 11/23/2006 (6925 days ago) |
| Assigned | |
| Resolved | 11/23/2006 (6925 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Not A Bug
be legit. However:
- you _have_ to get us the client's IMP version. there's really
nothing we can do otherwise.
- IMP uses c-client, through PHP's imap extension, to do IMAP traffic.
You won't find UNSELECT anywhere in IMP's code, and it's highly
unlikely that we can control whether or not it's sent.
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ UNSELECT command sent when connection not in selected state
Queue ⇒ IMP
I just picked the one I did because uncertain was not an option.
I'm an IMAP server developer and base my comments below on what a
trace/dump of my server from a customers site showed me while working
on an unrelated problem.
RFC 3691 added the UNSELECT command to the IMAP protocol. UNSELECT
moves a connection from the selected state to the unselected state.
The command is only a valid command if the client is in the selected
state. But it seems like IMP often sends an UNSELECT command when the
connection is not in the selected state. This is a needless network
round trip and added work for both the IMAP server and the IMP server.