St , 
   I have been looking at this issue , i dont see anything wrong might be i am
missing the obvious could you elaborate on what is exactly is not rendered
properly .

The messages - click on one of the messages. Sorry, I should have mentioned that.

Let me confirm you are stating that the messages bodies in html format are now 
rendered as it is seen(plain text with tags) in html .

correct. I would expect a table with some bold text and not HTML tags.

Understood thanks for confiriming i have filed an internal issue to the
engineers awaiting their response.

The engineers are actively investigating on the exact reasons why the html
bodies are not been rendered while viewing the html files . Would be updating
this issue when more information is made available .

-Jobin.

No update yet on this; checking again.

Updating Status whiteboard.

Thanks,
Karthik
Support Operations

CN dicussed this issue with Stefan. This issue is related to other similar 
issues around the vulnerablity of Cross-Site Scripting. The current behavior is 
introduced in an effort to disallow unsafe tags. 

Further investigation is underway on this issue.

The following lists are affected:
allfeatures@openoffice.org
cws-announce@openoffice.org
interface-announce@openoffice.org
features@<project>

Discussion is in process on how we could bring back this feature from the
current implementation keeping in mind the security factors in place .

Have not recieved further inputs in this issue as of now internally . Still
awaiting feedback on this issue .

Stefan , 
     The engineers have highly recommended that we retain the fix to prevent
cross site scripting .Since the possibility of cross site scripting via the
mailing list archive is more.The implementation/design of our HTML escaping
tools are to not escape individual tags i.e escape the entire value in the
message even if there is a unsafe tag present.

Hope the above clarifies our stand in this issue .

I understand where you are coming from.
But what solution do you propose to provide a way to read our messages again?

Stefan , 
    I really dont know if there is a way to provide the feature that you are
requesting . However let me check with the engineers if there is any alternative
option though the chances are very slim .

-Jobin.

I'm not requesting a feature. From the users point of view we are talking about
a DEFECT - a regression compared to 2.6.

Let me repatriate we don't consider this issue to be an defect. We had block
this feature due to the serious implications on the site whereby you to disable
_all_ of XSS filtering across the entire site,opening up scripting
vulnerabilities and/or potential rendering issues. 

The alternative(s) at this point is a one-off/instance-set. This
could be include either of these general ideas:

1. An override to the mailer viewer velocity template(s) to
   get rid of the escaping during message viewing.
   
   Consequence: makes this area vulnerable to XSS since what
   the browser is interpreting is user-defined data.

2. Override our Filter (Turbine) and create a new one this new filter 
could escape _only_ those individual  tags deemed in proper.
   
   Consequence: We don't believe there is a way for the filter to 
   limit the new filtering scheme to the mail reader.  All other parts
   of CEE would be subject to the new escaping scheme.
   Analyzing each tag would mean that much extra processing time
   for every tag on every single page served across the App. This
   _could_ imply performance degradation.

Please get back to us on the options which you would prefer .

Please update this issue with the option that would be preferrable for Openoffice.

It seems only option 1 targets the problem without unwanted side effects in
other areas. As HTML content is stripped for new messages it looks appropriate
to do the mail rendering without escaping.

Thanks Stefan have informed the same to the engineers.

Awaiting response from the engineers.

Stefan , 
     Based on the core engineers feedback we have decided that this issue or
option which was choosed could be done via an inst set . Hence currently we are
awaiting feedback from the inst engineer on effort involved in implementing this
solution .

To CRM 

Still awaiting response from the engineers.

From the internal discussion with the engineers we are considering on a fix for
this issue via the Inst-Set during the upgrade run up to Snake-S .

Archiving :

Hello Stefan , 

This is a follow-up based on our con-call(3/13/07) for the issue 

http://www.openoffice.org/issues/show_bug.cgi?id=66821

As you might recall the one thing that was specifically brought out was
that you would require skip filtering for a small number of mailing
list. In order for our engineering to move forward with the
implementation of a solution , we would require you to provide us the
list those mailing list.

-Jobin.

I am bringing down the priority for this issue as there has been no update so
far which would be enable us to proceed on providing a fix for this problem .

Any updates on this issue we would appreciate if any information is provided
regarding the questions asked in the desc27.

We are awaiting the list containing the various mailing list where the skip
filtering should be implemented .If provided soon we would be able to continue
our investigation/implementation of the solution as suggested in the conference
call .

Also on looking into the new Discussion Service have found that the html
rendering of all the messages is retained however in a more secured manner where
any messages containing html content are stored/captured as an attachment .
Hence when we do open the attachment html content is rendered as it was sent by
the user. 

Also attaching a screen of the attachment containing the html content. 

Based on the information provided resolving this issue to Resolved-Later.

Please re-open this issue if we would like us to look at the options as
mentioned in the previous comments.

Created attachment 47281 [details]
Attachment_with_proper_html_rendering

Updating the issue with the appropriate milestone .

CollabNet Support is currently reviewing the issues under Resolved-Later. If the
issues are fixed currently in any of the present CEE releases, then it will be
marked as Resolved-Fixed.

There might be a few issues which might not be in our future roadmaps which
might be closed as Wontfix unless it does not lie under any custom request.

Marking this as Resolved fixed as it has been provided in DS as stated in desc31.