Tickets :: Comment on [#14841] Send mail over ActiveSync

* Your Email Address
* Spam protection	Enter the letters below: __.. \ / __ . (__ \| >< / `\| .__)\|___/ \\__.\|___
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries