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

BINARY vs BODY and "invalid" messages #6383

Closed
tomsommer opened this issue Aug 6, 2018 · 5 comments
Closed

BINARY vs BODY and "invalid" messages #6383

tomsommer opened this issue Aug 6, 2018 · 5 comments
Milestone

Comments

@tomsommer
Copy link
Contributor

Roundcube uses BINARY.PEEK whenever possible, however this prevents the display of broken mails, that usually work with BODY.PEEK

BINARY.PEEK returns UID NO [PARSE] Invalid data in MIME part (0.012 + 0.000 + 0.011 secs) whereas BODY.PEEK returns the mail body.

Perhaps add a fallback to BODY.PEEK if BINARY.PEEK fails?

@tomsommer tomsommer changed the title BINARY vs BODY and "corrupt" messages BINARY vs BODY and "invalid" messages Aug 6, 2018
@alecpl
Copy link
Member

alecpl commented Aug 6, 2018

There's a fallback, but we use it only on [UNKNOWN-CTE] response. Maybe we should do this also for [PARSE]. What IMAP server/version?

@tomsommer
Copy link
Contributor Author

Dovecot 2.3.2

@alecpl
Copy link
Member

alecpl commented Aug 6, 2018

Looks like dovecot 2.3 uses [PARSE] instead of [UNKNOWNCTE]. https://www.dovecot.org/list/dovecot-news/2017-December/000366.html

@alecpl alecpl added this to the 1.3.8 milestone Aug 6, 2018
@tomsommer
Copy link
Contributor Author

Good catch, Dovecot can return both UNKNOWN-CTE and PARSE now: dovecot/core@ff17313

alecpl added a commit that referenced this issue Aug 6, 2018
alecpl added a commit that referenced this issue Aug 6, 2018
@alecpl
Copy link
Member

alecpl commented Aug 6, 2018

Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants