Syntax error in MODSEQ. Unexpected atom token: -1 about mailkit HOT 6 CLOSED

@HochzeitManagement yes, this log is perfect! Thank you.

S: * 39 FETCH (MODSEQ (0) FLAGS (\Recent \Seen) UID 290)
S: * 40 FETCH (MODSEQ (-1) FLAGS (\Recent \Seen) UID 336)

Sure enough, the IMAP server is sending us a value of -1. It's also sending us a value of 0 which I think is illegal, but MailKit already handles that.

I'll work on writing up a work-around now that we have verified that it really was sending -1.

from mailkit.

@jstedfast so sorry, I haven't had time yet as I need to check this locally. hope to get to it quickly. thanks.

from mailkit.

Hard to know for sure based on just a stacktrace (I'd need a protocol log), but it looks like the IMAP server tried to send -1 as a MODSEQ value which is defined by the IMAP specifications as a non-zero unsigned 64-bit integer (i.e. it can't be a negative value or 0).

I've taken a look at the code, and assuming that my theory is correct, 4.3.0 will also throw this exception in this scenario.

If you could get a protocol log for this scenario, I will take a look and see if I can implement an appropriate work-around to avoid throwing an exception.

Can you confirm that subsequent connections for this customer seem to work? I am wondering if this happens if the IMAP server hasn't yet assigned a MODSEQ value or something (i.e. there is some sort of inconsistent state in the IMAP server and this causes it to write -1 for the MODSEQ value instead of a real value).

If this is the case, I think the appropriate work-around might be to treat -1 as if a value wasn't sent at all (in other words, treat it as if a MODSEQ value was not present at all).

The other possibility that I can think of is that the IMAP server is using a 32-bit int instead of a 64-bit unsigned int and the IMAP server code is suffering from an integer overflow bug, making it such that we might have to treat -1 as a valid value (which might get complicated).

from mailkit.

Would be good to know what the IMAP greeting is as well, so I can add it to my list of server-dependent work-arounds.

FWIW, the ProtocolLogger defaults to redacting authentication secrets starting with MailKit v3.1.0, so you won't need to do anything special to hide those if you get a log.

All I really need from the log is the first line after the "Connected to ..." message and the line matching * # FETCH (... MODSEQ -1 ...) (if there is one - I mostly just need this to be confirmed).

I'm pretty confident (~99%?) that there will be a response line with MODSEQ -1, but I am not 100% certain.

from mailkit.

@HochzeitManagement Any update on this?

from mailkit.

imap-mailkit.log
here the imap log. is it helpful for you? what can we do? thanks

from mailkit.