[Tickets #14841] Re: Send mail over ActiveSync - lose content
noreply at bugs.horde.org
noreply at bugs.horde.org
Sat Aug 11 20:53:54 UTC 2018
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: https://bugs.horde.org/ticket/14841
------------------------------------------------------------------------------
Ticket | 14841
Updated By | Michael Rubinsky <mrubinsk at horde.org>
Summary | Send mail over ActiveSync - lose content
Queue | Synchronization
Version | FRAMEWORK_5_2
Type | Bug
State | Feedback
Priority | 1. Low
Milestone |
Patch |
Owners | Michael Rubinsky
------------------------------------------------------------------------------
Michael Rubinsky <mrubinsk at horde.org> (2018-08-11 20:53) wrote:
>> When the content is base64 decoded, you can see that the
>> result is incorrect HTML (actual content removed for privacy):
>>
>> <div dir='auto'>blah blah blah<div
>
> I see this open end, but you mean the client "stop sending" in
> middle of the html code?
The way "SMART" replies work is the client only sends the content of
the reply to the server. The server then fetches the content of the
original email (using the ItemId/FolderId sent in the SmartReply) and
appends it to the reply text that was sent from the client. I.e., it
only sends the new text that you compose, not the original content
that you are replying to. So, the text you see when you decode the
base64 in the <ComposeMail:SmartReply> element is expected to only
contain the text that YOU composed. There is no filtering that is done
by Horde to the content of the SmartReply that you see in the log -
this is raw data from the client. If it's broken here, it's broken by
the client.
> If I decode the base64 I see only my broken answer, but was there no
> filter before?
> I do not see the original reply text in the base64 decode (but in
> IMP), where is this text appended?
This is correct. It's how SMART REPLY works. It's designed to save
bandwidth between the EAS client and server. The server is responsible
for grabbing the content of the original email that you are replying
to and quoting/appending it to the message body that is sent from the
eas client.
>> The result is that when the message you are replying to is
>> concatenated to your reply text, the result is badly formed HTML,
>> with most of the text looking like it's part of an unclosed div tag.
>
> This is the question, who drop this text/html.
The content of the ComposeMail:SmartReply is expected to contain only
the reply text. I'm not sure what your full text was when you wrote it
so I don't know what is being truncated there, if anything but I can
tell you that the text being sent is broken html. Either way, whatever
is causing that badly formed HTML is definitely coming from the client.
More information about the bugs
mailing list