-
Notifications
You must be signed in to change notification settings - Fork 86
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
mox corrupting 822 email part 0.0.9 #117
Comments
I found this on precompiled mox 0.0.8 on Linux amd64 It is not present on compile-from-source 0.0.9 arm64 macOS 1d9e80f |
This still exists after upgrade to 0.0.9 linux-amd precompiled So far it only happens when using a TLS connection across a network segment to Linux/amd A key issue is that it happens at a line ending in some mime part 64 KiB or more into the email Because it is always at a line ending, this is unlikely to be a socket or networking issue The msg directory can be examined by
one can also examine files:
|
Actually the client used, which is the least garbage among all the Go imap garbage out there, if the delay between two such chunks is longer than the time to receive a chunk, then mox will receive chunks separately possibly, mox is unable to handle receiving a literal across multiple read invocations, and mox does that reception somehow involving newlines and therefore erroneously inserts a cr. possibly The changed bug behavior in 0.0.9 changes the byte-slice length Update: running against a temporary-storage mox via bidirectional stream does not fail either |
TOTAL BUG server.go:2729 just read the literal to file correct length msize the bug is message.NewWriter that parses literal and inserts \r. in the LITERAL? that’a a NONO |
Here’s a fix to the very serious fatal not good indeed email corruption bug
|
thanks for staying on this!
i suspect this is the real problem, and what needs fixing. the cr/lf accounting in message.Writer.Write may be lacking.
mox requires all messages in the store to end with CRLF. in part because IMAP servers are required to serve messages that way, and in part because the message mime parser would become more complicated. i.e. the more you accept and store malformed messages, the more it ripples through other pieces of code, making them more complicated and leading to bugs, including security issues.
part of the reason mox has its own mime handling code: the parsed form of a message (including byte offsets to the parts) are stored in the message index database. it's all a bit more integrated than in many other software. question: which byte sniffing in mox do you think has issues, and which issues? i'm going to dive into that message.Writer, and figure out where exactly the problem is. |
…riting a message message.Writer.Write() adds missing \r's, but the buffer of "last bytes written" was only being updated while writing the message headers, not while writing the body. so for Write()'s in the body section (depending on buffering), we were compensating based on the "last bytes written" as set during the last write in the header section. that could cause a spurious \r to be added when a Write starts with \n while the previous Write did properly end with \r. for issue #117, thanks haraldrudell for reporting and investigating
i reproduced the problem of the spurious \r and wrote a test that is only triggered without the fix. |
v0.0.10 is coming soon, it has instructions for finding & fixing up messages that have the \r\r\n line endings. Closing this for now, we can reopen if needed. |
I have a 32,262 byte message that mox is corrupting by inserting an extra U+000D
The insertion is at index 12,973
The corruption is in the html mime part. There are lots of lines, but the message is always corrupted at the same place
— at the end of a particular line, a CR is converted to CR CR
version: 0.0.8
with this bug mox cannot be used
an imap server corrupting messages is not OK
— I was able to verify that on the socket sending to mox, the extra CR is not present: mox is receiving good data
— In mox file-system store, the extra CR is present. mox is storing BAD data after receiving good data
— on retrieving the message from mox, the length is correct but the inserted CR causes the final U+000A to be lost
mox should not be tampering or filtering the opaque rfc822 bytes
if mox gets corrupt rfc822 in, it should send the same corrupt rfc822 out
— I would suggest to implement sha256 hashing that would detect corrupt data
— this would detect software bugs or file system errors
— use a type with both the byte slice and the hash, say first 8 character-array, then always have them go together
— if the server reads corrupt data from disk, it should stop serving requests
— I have also seen other people using Go scanners intended for text on their sockets, that may not work for imap
The text was updated successfully, but these errors were encountered: