Description
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