Our mail server functionality currently use Rebex IMAP component.
One of the system responsibility is to put INBOX emails in a database.
To check if email already is in a database system find FolderId + UniquieId combination in a database table.
Our previous Imap provider returned string view of integer value, that was unique per an email account.
Rebex Imap provider returns string unique ids like "ECvRWUABEHN". That could be ok, if Rebex documentation would contain any info about that, and, what actually was critical point, that text representation of Rebex provided UniqueI IS CASE SENSITIVE.
That way, in pretty short time range in INBOX email accouint folder can appears two different emails with "ECvRWUABEHN" id and "ECvRWUABEHn" id.
The most database text configurations are CASE INSENSITIVE, so operations like DISTINCT, WHERE MessageUIN = @MessageUIN are CASE INSENSITIVE too, so Rebex style UniquieId values can seriously affects current data access and business logic, and in our case ACTUALLY DID IT.
You MUST provide more detailed documentation about things like described above.
Short description like (quote from Rebex documentation) "Gets the message unique ID.
" is absolutely not enough.
For now, my question is: can you change UniqueId representation such way that it will be case insensitive. Case sensitive operations on case insensitive databases is serious performance hit.