On 21.5.2013, at 21.24, Michael M Slusarz <slus...@curecanti.org> wrote:
>> Or are you saying that the error is fine if the text contains NULs, but >> simply should be allowed as long as it doesn't? > > This. As mentioned before, it seems the code is simply assuming that the > text part contains NULs without ever checking it. My reading of the literal8 > is that there is no requirement that NULs MUST exist in the string. > > In our code, the append data is often from code that the IMAP library doesn't > have access to. So at APPEND time, it is unaware whether the data contains > NUL or not - it just has a blob of data and a length. If BINARY exists, it > is much easier for us to simply send as literal8 and stream the data - no > extra overhead is needed on our side. Since each individual byte need to be > handled by the server as it comes in, it seems much more efficient to do NUL > checking there. It's not just about NUL. It's also about if plain LFs can be converted to CRLFs. Anyway .. the BINARY APPEND converts only the MIME parts that you send with "Content-Transfer-Encoding: binary". Are you sending such header to Dovecot? If not, there's actually no difference to a regular APPEND from Dovecot's point of view (I think). If a non-binary MIME part contains NUL, what is Dovecot supposed to do? Change it to some other character? Fail the APPEND? Should there be a difference between how literal vs literal8 is handled in such case?
