Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2: in capability-data: imapwire: expected atom, got \"\\r\"" #571

Closed
uuthink opened this issue Dec 14, 2023 · 6 comments
Closed

v2: in capability-data: imapwire: expected atom, got \"\\r\"" #571

uuthink opened this issue Dec 14, 2023 · 6 comments
Labels
non-standard Interoperability with software violating the specs

Comments

@uuthink
Copy link

uuthink commented Dec 14, 2023

Sometimes while fetching a mail with UIDFetch I get the following error:

Expected nil, but got: &errors.errorString{s:"in response-data: in capability-data: imapwire: expected atom, got \"\\r\""}

Here are the logs

* CAPABILITY IMAP4 IMAP4rev1 XLIST MOVE IDLE XAPPLEPUSHSERVICE NAMESPACE CHILDREN ID UIDPLUS 

I noticed that there is a space before the ending newline character

I try to modify the SP method to solve this problem. The modification is as follows. Is it correct?

func (dec *Decoder) SP() bool {
	if dec.acceptByte(' ') {
		if dec.CRLF() {
			dec.mustUnreadByte()
			return false
		}
		return true
	}

	// Special case: SP is optional if the next field is a parenthesized list
	b, ok := dec.readByte()
	if !ok {
		return false
	}
	dec.mustUnreadByte()
	return b == '('
}
@emersion emersion added the non-standard Interoperability with software violating the specs label Dec 14, 2023
@emersion
Copy link
Owner

Seems similar to #540

I'm worried about calling mustUnreadByte after CRLF though. I think I'd prefer peeking at the next byte and checking whether it's \r or \n.

@uuthink
Copy link
Author

uuthink commented Dec 19, 2023

Thank you very much, I will using dec.r.Peek(1) to get the next byte and checking.
Is this a bug? or is it caused by not strictly following the RFC? and it will fix in the furture?

@emersion
Copy link
Owner

This is a server bug: they are not strictly following the RFC's grammar.

@duesee
Copy link

duesee commented Jan 22, 2024

Hey @uuthink, can you say which server generated the CAPABILITY response with the trailing space?

qjebbs added a commit to qjebbs/go-imap that referenced this issue Feb 23, 2024
* a compliant response should be like: * CAPABILITY IMAP4<SP><SP>IMAP4rev1<CRLF>
* this commit compatible with the following response: * CAPABILITY IMAP4<SP><SP>IMAP4rev1<SP><CRLF>

related: emersion#571
qjebbs added a commit to qjebbs/go-imap that referenced this issue Feb 23, 2024
a compliant response should be like: * CAPABILITY IMAP4<SP>IMAP4rev1<CRLF>
this commit compatible with the following response: * CAPABILITY IMAP4<SP><SP>IMAP4rev1<SP><CRLF>

related: emersion#571
@emersion
Copy link
Owner

emersion commented Mar 6, 2024

For reference, cc @duesee

imap.exmail.qq.com sends:

* CAPABILITY IMAP4<SP>IMAP4rev1<SP><CRLF>

smtp-n.global-mail.cn sends:

* SEARCH<SP><CRLF>

@emersion
Copy link
Owner

emersion commented Mar 6, 2024

Fixed in #596

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
non-standard Interoperability with software violating the specs
Projects
None yet
Development

No branches or pull requests

3 participants