https://bugs.kde.org/show_bug.cgi?id=368003

Jan Kundrát <j...@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|                            |http://commits.kde.org/troj
                   |                            |ita/d9a728d49cef4457afdf069
                   |                            |6942a848e82951815
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Jan Kundrát <j...@kde.org> ---
Git commit d9a728d49cef4457afdf0696942a848e82951815 by Jan Kundrát.
Committed on 01/09/2016 at 18:48.
Pushed by gerrit into branch 'master'.

Use correct CTE when attaching IMAP parts

Because we are making a heavy use of the CATENATE extension which uses
the raw, undecoded data from the IMAP server without any transformation,
let's make sure that the attached part inherits its
Content-Transfer-Encoding from the original part. This ensures that the
attachment is added as-is, with no additional transformations and is
still correctly marked.

A potential problem is that when attaching a part which is
malformed/invalid or if it contains data which are not permitted by a
relying MTA, we might hit problems. However, in that case it would be a
garbage-in, garbage-out problem. There's a hypothetical scenario where
an IMAP message contains a binary, non-encoded part, which this patch
happily ignores. However, it isn't a regression but rather an
improvement -- at least such part is properly marked with a CTE that
reflects its actual content.

This patch still doesn't enforce a 100% byte-by-byte match of the
outgoing message (as submitted over SMTP) and the copy stored in the
Sent folder. If CATENATE is available (it is with Dovecot for example)
and BURL is not available (BURL is still a bit exotic today), and if
attaching something which is already available on the IMAP server, there
might be subtle differences such as the wrapping of the base64 content,
etc. That's the price one pays when offloading stuff to the IMAP server,
and I do not see any possibility of avoiding it (except maybe tying BURL
and CATENATE together and only ever using both or none of them...).

Change-Id: I53a2a186f308a9acab3b1d5f4e3e821e29bbb3ce

M  +30   -7    src/Composer/ComposerAttachments.cpp
M  +1    -0    src/Composer/ComposerAttachments.h
M  +9    -1    src/Composer/MessageComposer.cpp
M  +39   -3    tests/Composer/test_Composer_Submission.cpp

http://commits.kde.org/trojita/d9a728d49cef4457afdf0696942a848e82951815

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to