You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
We on our project stumbled upon using ImapFolder.Search(SearchQuery.DeliveredAfter(date)) method.
Constantly getting "UID SEARCH Backend error" response from imap server.
After investigating the issue I found that there is a ImapFolder.FormatDateTime method that converts date representation to uppercase. Removing the conversion fixed the issue.
I wonder if this conversion is there for purpose (perhaps the things are vice-versa in some other IMAP server implementations that expect uppercase dates only)?
Anyway the RFC3501 specifies that the month names in a date represenation must start with first capital letter the rest are lower-case (e.g. Jan, Feb, etc.)
So if the currently applied uppercase convertion is not a compatibility measure it would be good to change it to comply with RFC since definetly there are IMAP servers that expect dates strictly in RFC3501 format.
The text was updated successfully, but these errors were encountered:
Hello,
We on our project stumbled upon using ImapFolder.Search(SearchQuery.DeliveredAfter(date)) method.
Constantly getting "UID SEARCH Backend error" response from imap server.
After investigating the issue I found that there is a ImapFolder.FormatDateTime method that converts date representation to uppercase. Removing the conversion fixed the issue.
I wonder if this conversion is there for purpose (perhaps the things are vice-versa in some other IMAP server implementations that expect uppercase dates only)?
Anyway the RFC3501 specifies that the month names in a date represenation must start with first capital letter the rest are lower-case (e.g. Jan, Feb, etc.)
So if the currently applied uppercase convertion is not a compatibility measure it would be good to change it to comply with RFC since definetly there are IMAP servers that expect dates strictly in RFC3501 format.
The text was updated successfully, but these errors were encountered: