Conversation
| imap.CapMove, | ||
| imap.CapStatusSize, | ||
| imap.CapBinary, | ||
| imap.CapChildren, |
There was a problem hiding this comment.
Could CHILDREN be submitted independently in a separate PR? That way, it can be merged right away.
There was a problem hiding this comment.
moved children to own PR
|
What is the motivation for adding ID? I find this extension to be harmful in general, because it's privacy-intrusive and enables both sides to write workarounds instead of proper fixes for bugs and non-standard behavior. |
It's for debugging and client support only. Often they have multiple clients connecting so knowing which client they use for which connection helps trace their possible issues. It's also helpful to know which IP / which client so they can have a simple security audit. I don't think the worry for privacy belongs here - the trust is assumed on IMAP service between client and server by definition. |
|
I've updated the PR for Dovecot forwarding support which is more critical use of ID as per |
These simple capabilities are not depending on go-imap and can be made available?