Genii Weblog

Would you like that windmill rare or well done?

Tue 5 Aug 2014, 08:58 AM

by Ben Langhinrichs
If your company uses Notes/Domino for email, you have probably learned that in spite of years of customer complaints, emails sent from Notes are iffy at best. On a good day, all the information gets through. On a bad day, data is misformatted, missing or just plain messed up.

But it is just for such concerns that we at Genii Software tilt at the windmills of email fidelity and data integrity. Now, since the release of CoexLinks Fidelity 3.6, more and more companies are getting their windmills served up just the way they want them. (No point in tilting at something if you can't serve it for supper.) If you want a short technical explanation, see the bottom of this post. If you just want to try it for yourself, request an evaluation license.

In 2014, using IBM Notes 9.0.1 Social Edition, you send the following email:.
Original email in Notes 9.0.1 rich text

With native client rendering, it arrives in Gmail as:
Email as sent to Gmail after Notes 9.0.1 MIME rendering

With CoexLinks Fidelity rendering, it arrives in Gmail as:
Email as sent to Gmail after CoexLinks Fidelity MIME rendering

With native client rendering, it arrives in Outlook 2007/2010/2013 (no rendering changes in years!) as:
Email as sent to Outlookl after Notes 9.0.1 MIME rendering

With CoexLinks Fidelity rendering, it arrives in Outlook as:
Email as sent to Outlook after CoexLinks Fidelity MIME rendering

and it is not just the client rendering. What if you view the same email (still in rich text) via your Notes client or your iNotes client? Note that while the images work here, they will fail if mailed from here, unlike the images with CoexLinks Fidelity.

In IBM iNotes on Domino 9.0.1:
Email in rich text viewed through iNotes 9.0.1 with native rendering

In IBM iNotes on Domino 9.0.1 with CoexLinks Fidelity:
Email in rich text viewed through iNotes 9.0.1 with CoexLinks Fidelity rendering

A brief technical explanation of the specific areas which fail here:

1) Image resources in emails are converted to relative URLs by the client MIME rendering, which means they fail unless the email is read on the server where it was sent. The same issue means that the iNotes native rendering will work when viewed, but fail when sent. Real life scenarios: Note that while image resources are seldom added directly to emails, they are sent frequently when a document is forwarded. The images will look fine for the sender but be missing for the recipient. There is no easy way for the sender to know if images are inline or image resources. CoexLinks Fidelity solution: Image resources are brought inline before rendering. To avoid large sizes, the same image resource is only included in the MIME once even if it is displayed multiple times.

2) Table width. This problem surfaced due to a customer's confusion about why a table that was small and fixed in size was spreading across the entire width of an email. It turned out that a nicely constructed email newsletter had a table where the table was set to "Fit with margins", but every column was a fixed width. When that happens, the Notes/Domino rendering simply sees it as a variable width table. CoexLinks Fidelity solution: When all columns are fixed width, the table is treated as a fixed width table.

3) Non-uniform cell borders. Toward the end of the last millennium, a table in HTML either had borders or did not. After the introduction of CSS in 1996, tables in HTML with CSS could be on or off depending on the cell, something that had been true in Notes rich text for a long time already by then. Unfortunately, IBM has been slow to convert the non-uniform cell borders in Notes to non-uniform cell borders in HTML+CSS. To be fair, the Notes 9 client rendering does finally accomplish this, but the Domino 9 rendering does not. Thus, you can see the borders in the two samples above that were sent with Notes 9.0.1 rendering, but not in the iNotes rendering. Real life scenarios: Both newsletters and forms often use cell borders to make the appearance more sleek and professional. When these are sent or forwarded, the sender may not anticipate how the tables will look to the sender. CoexLinks Fidelity solution: CSS is used to match the non-uniform cell borders in Notes.

4) Table borders. Separate from cell borders, there is a table border which is often used for drop shadows but also for framing. Both Notes 9.0.1 and Domino 9.0.1 seem to ignore it in all their rendering engines. Real life scenarios: Newsletters, forms, and reports often use table borders, both for a professional look and, sometime, to separate out small tables. All is lost when these are rendered by Notes/Domino, no matter which rendering engine is used. CoexLinks Fidelity solution: Table borders are used, as well as inner and outer padding. As you can see in the Outlook example, not all email systems will recognize the inner and outer padding.

5) The color of green. In an odd quirk, the Notes client rendering confuses light green and dark green, so that both appear as dark green in emails. (I first reported this to IBM in 2007, fwiw.) This can lead to tables that don't look as they should, and occasionally to the perception of missing data as in this example. Real life scenarios: As two of the sixteen basic colors in Notes, both light and dark green are used more frequently than other colors. I have seen customer examples with the light green lettering on the dark green background which leads to this, which is why I added it to the demo. CoexLinks Fidelity solution: RGB colors are used to ensure consistency.

Copyright 2014 Genii Software Ltd.

What has been said:

1066.1. Ben Langhinrichs
(08/05/2014 03:33 PM)

I have a feeling that this is addressed in CoexLinks Fidelity 3.7 (our upcoming release where we deal with inbound messages as well as outbound), but I tried just now and couldn't reproduce the problem with the Outlook 2007 I have on this machine. Could you send me two invitations following your steps and I'll try them and make sure. (Sending this as email as well in case you don't stop back by right away.)

1066.2. Ben Langhinrichs
(08/05/2014 03:55 PM)

In any case, let me know how the INI variable works for you. I've been looking through my notes, and I am not sure whether we handle the winmail.dat directly or simply take the one converted by Domino if you use the TNEFEnableConversion=1 and make it a proper invitation. I should be able to find out tonight.