CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
Daniel Nashed – 10 October 2016 07:41:42
We ran into an issue at a customer on Friday. Today we got the confirmation that it is a bug and development is already looking into this. It looks like a low level issue when converting Richtext into MIME in mails on server side.
In my test I have seen than probably all server based conversions are affected. Clients sending MIME message directly do not show this issue (and that should be the default in hopefully most companies so it hopefully is not an issue for your users).
When the server converts a message to MIME JavaScript is generated for collapsible sections (for example when you reply to a mail in Notes style and your client prefers richtext when sending internet mail).
There have been some changes in the conversion code in fixpack 7 which might have caused this unintended change.
We have seen this when mails are converted by the mail-router and also 3rd party applications that convert messages.
The SPR we got from support todays show it also impacts POP3 and IMAP.
The critical part of the issue is that Javascript in mail is rated as active content by many antivirus/spam software. This can lead to rejected mails and even negative score for the sending servers.
The only work-around is to ensure your clients are sending MIME directly and don't use the option to send richtext to internet recipients.
Format for messages addressed to internet addresses: Notes Rich Text Format -> MIME Format.
You can ensure clients use that setting by pushing the setting via desktop policy. In our case the initial value was set correctly but the setting was not enforced and users changed it.
But this can also occur with agents sending messages in richtext -- For example with newsletters etc..
-- Daniel
SPR #AJASAEHJKB
Reply Section Or Twistie In A Cd-mime Conversion Is Converted Incorrectly In Fixpack 7
With a location doc which specifies to send to the server in
Format for messages addressed to internet addresses: Notes Rich Text
Send a typicall reply chain memo to 9.0.1 Domino FP6 for conversion either external or to a POP or IMAP user who has a
Prefers Mime on their location doc and it will be noticed that after upgrading Domino to FP7 the arrows are missing and the
format looks not quite right, the arrows are replaced by javascript links in the received note
- Comments [9]
1Oliver Regelmann 11.10.2016 7:45:52 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
Oh, what a fun. If you've got something running that converts your internal mail to MIME format (for example to add some images to the mail signature), you'll get JavaScript errors opening every internal mail ("document.GetElementByID is not a function")
BTW: Sending rich text format to external addresses isn't a good idea anyway because the server removes embedded images during the MIME conversion.
2Lars Berntrop-Bos 11.10.2016 13:56:10 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
I've recommended a hold on upgrade to FP7 based on this bug.
Perhaps FP8 will be published sooner?
3Daniel Nashed 11.10.2016 16:10:22 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
@Lars, I hope they have a fix soon and will put it into a IF.
In combination with the iNotes locale issue this would be worth a IF
4Daniel Nashed 11.10.2016 16:11:21 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
@Oliver, in my customer case they did not set "richtext" for outgoing internet mails on purpose.
In our case we changed the desktop policy from "set once" to "prevent changes" and it is quite OK now for the customer.
But you don't always controll the way mails are send for example with agends where you don't want to deal with MIME directly.
Also the problem occurs for mails that are read via POP3 and IMAP and all other server based conversions.
-- Daniel
5Jay Marme 11.10.2016 19:22:17 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
I think that it is more likely that an Interim Fix will be issued for FP7.
6John 13.10.2016 16:00:05 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
Its only an issue if you have your Notes client set to send messages out to the internet as Notes Rich Text. The recommended setting is to use MIME to cut down on overhead (server side) performing CD to MIME conversions. So most will never see this problem.
7Daniel Nashed 14.10.2016 7:24:42 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
@John, I agree that would be the best and the recommended setting. And in our case we changed the customers desktop settings to enforce the settings and that users cannot change it any more.
But if example when you send out mails via agents and you don't want to deal with the MIME encoding the mail will be richtext as well when it arrives at the router.
And there are also other cases where this can cause issues like for POP3 and IMAP.
I will add one more commend to the blog post to make it more clear that the standard setting is MIME.
-- Daniel
8Kai-Uwe rommel 20.11.2016 19:43:08 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
I had reported this problem via an PMR during end of September. There is a scenario where you will want the client to send rich text to the server and have the Domino router convert to MIME when messages are destined to Internet recipients: this is when you use some 3rd party solution that manages e-mail signatures and needs to insert or append signatures with an extension manager hook on the server. In such cases the software will require rich text instead of MIME from the client because rich text is easier to parse when the signature must be inserted between new text and the appended history text. We use such a solution (TreeMailS) and because of this bug we had to go back to FP6+IF3.
9Michael Killoran 22.11.2016 0:03:24 CD to MIME Conversion Issue in 9.0.1 FP7 generating Javascript for sections
Sorry about that. This regression was caused by a change I made to browser.cnf to let sections work with the edge browser. I neglected to take the HAPI use case into consideration. A hotfix for this SPR is now available. A workaround would be to edit browser.cnf as follows:
Property DHTMLSections String Standard
to
Property DHTMLSections String None