Re: [Evolution] How does evo determine when to base64 encode?
On Tue, 2016-02-16 at 22:25 +, Johnson, Brett E (HP Cloud Linux R&D) wrote: > Here at work, I've recently had a msexchange account shoved down my > throat, and > 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? Evolution determines how to encode the message body based on its content. It tries to pick the best encoding (the one which generates smallest encoded blob). If your message body contains too many non-ASCII (non-7bit) letters, then either quoted-printable or base64 encoding is used. > 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 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. The message itself is decoded and shown properly in UI (if it's not, then it's an issue on the client's side; I remember Evolution used to have problem showing base64-encoded messages too, but I think it's not true at least since 3.18.x). 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. 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 ... The content of 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. Checking message source in the Sent Items folder shows me pretty much the same, no base64 encoding at all. 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 protocol. Each behaves differently and your Outlook can use MAPI, not EWS. In any case, the debugging will show what is passed to the server. Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] calendar timeout? -
On Wed, 2016-02-17 at 09:58 +0100, Herr Oswald wrote: > my message seems not to come to the list (attachments forbidden?). > So I'm sending it directly to you - hope you can do something with > it. Hi, it might be because the log is too large, the whole message size is ~102KB. The log doesn't show much, just many rejects from the server with 403 error, due to no authentication being tried. Yours 3.16.5 is trying to access some ownCloud server, according to headers there. You should make sure that the calendar has set Username, which is used as a notice that the server requires authentication. It's supposed to be pre-filled in your sources, when you have it configured through GOA. I recall some changes in the CalDAV authentication, which are probably not part of your 3.16.5. It would be nice to try with 3.18.4 (there was a release of 3.18.5 this Monday, but it doesn't contain any related changes in the CalDAV code). I would try that in a virtual machine, using a distribution which provides the current stable version of the evolution-data-server and evolution. I would also try to configure (one of) the calendar(s) directly in the Evolution, not using GOA, just to avoid one part of the chain. You can fill only part of the server URL (hostname + some path prefix) and Username, then click "Find Calendars" and it may show you available calendars on the server, if the URL you gave it will be sufficient. It works better in 3.18.4 than in 3.16.5 too. Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] calendar timeout? -
On Wed, 2016-02-17 at 11:00 +0100, Milan Crha wrote: > > my message seems not to come to the list (attachments forbidden?). The rejection message from the list maintainers explains the reason for the rejection. It's usually because the message is too large (over 40k or so), not explicitly because of attachments. If you need to show large images or other data, please use a web service such as Pastebin. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
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 +, 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 > (in time of the send) and inside it also >... > The content of 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 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: 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 "Prestige is like a powerful magnet that warps even your beliefs about what you en
