Re: [Evolution] How does evo determine when to base64 encode?



Thanks Milan, for your help/suggestions!

On Wed, 2016-02-17 at 09:49 +0100, Milan Crha wrote:
On Tue, 2016-02-16 at 22:25 +0000, Johnson, Brett E (HP Cloud Linux
R&D) wrote:
I've noticed that, using evolution-ews, evolution almost always base64
-encodes
the body of my messages.  Yet, if I send the same message via SMTP, it is
not
encoded.

      Hi,
do you send exactly the same message using Evolution, once through an
evolution-ews account, another time using SMTP?

Yes.  I sent two message via EWS (one just plain text, and the other with some
minimal html italics/bold).  Then I sent the same messages (using "Edit as new
message") and selecting an evolution IMAP/SMTP account pointing at the same
msexchange server (via the "From:" menu).  The ones sent from the EWS account
are both received as multipart/alternative MIME messages with base64 encoding. 
 When sent from the IMAP/SMTP account, both are received also as
multipart/alternative, but the parts are sent with 7bit ascii encoding. 
 Finally, I composed the exact same message in OWA and sent it, and the result
was the same as evolution/SMTP, except the encoding for the text/html part was
"quoted-printable" instead of "7bit".


Can anyone explain this?  Is there any way to turn it off?

I do not think so. If the answer is 'yes' for my question above, then
it clearly means that it's not done by the message composer, because it
always produces the same result.

I agree it's not done by the message composer.  It must have something to do
with the EWS transport, but I don't really understand that part.

I really don't want to send out base64 encoded blobs to anyone

Why does it matter for you? You see the base64 encoding only if you
check the message source.

You're making the incorrect assumption that everyone uses a mail client that can
transparently decode mime/base64. I need to be able to send plain text emails,
especially in some circles/mailing lists where sending a non-plaintext email to
the list will get you publicly shamed and even banished.

By the way, there are circumstances where base64 encoding is required.
For example if you encrypt the message. The encrypted part contains
binary data (not text), thus the encoding is required to not have
modified the data by respective servers on the route from the sender's
machine to the receiver's machine.

Agreed, I understand this.  I'm not complaining about using base64 when it's
needed, only when it's not needed, and when I'm trying purposefully to send
plain text.

If you want to debug what the evolution-ews does when it sends the
message, then run evolution from a terminal like this:

   $ EWS_DEBUG=2 evolution

Then resend any message through the EWS account, once the initial buzz
will end. You should see in the output something like
   <messages:CreateItem ...
(in time of the send) and inside it also
   <Message><MimeContent>...</MimeContent>
The content of <MimeContent/> is the message as passed to the server,
encoded as base64 (that is required here, because the envelope is an
XML document). I sent a very simple message, which was Subject:test; in
body:test, and the decoded MimeContent showed:
   Content-Type: text/plain
   Content-Transfer-Encoding: 7bit
thus no base64 in the message itself at all.

Thanks, I tried this, and when sending via EWS, I see the same thing you do. 
 I.e. there's a base64 blob in between the <MimeContent></MimeContent> tags, and
if I decode that blob, it's the same thing that I see in the message sent via
SMTP.  Bizarrely, what appears in the message sent via EWS is the two
multipart/alternative parts, each base64 encoded separately. So, it's apparent
that it's the msexchange server doing the encoding, not evolution.  I wonder why
it's doing that when sent this way, but not when sent via SMTP?

With respect of the Outlook, I do not know what version of Outlook you
use, neither what version of the Exchange server you connect to, but
since Exchange 2007, the servers can be connected through MAPI and EWS. In any
case, the debugging will show what is passed to the server.

I think the outlook version is 2013, at least that's what the icon says.  And
I'm pretty sure it's connecting via EWS, not MAPI.  In the account
configuration, it has a bizarre-looking "server name" that looks like a UUID of
some sort, and the "Connect to Exchange via HTTP" box is checked.

I don't know what version of exchange is running in the galactic corp HQ.  The
debug output SOAP-ENV I generated above says:

<types:RequestServerVersion xmlns:types="http://schemas.microsoft.com/exchange/services/2006/types"; 
Version="Exchange2010_SP2"/>

Is that a return from a query?  Or is it the version evolution-ews supports?

In any case, I don't really know where to go from here.  Maybe it's a
misconfiguration of the exchange server, or maybe there's something in the
evolution-ews messages that makes exchange think it needs to encode the parts?

-- 
Brett Johnson<brett hpe com>
"Prestige is like a powerful magnet that warps even your beliefs about what you
 enjoy. It causes you to work not on what you like, but what you'd like to like."
  ~~ Paul Graham




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]