There's a bug when sending and retrieving HTML email from Domino that has been plaguing me for years now. Now I've finally decided to take the time to investigate fully and find a fix.

First, imagine the code below:

While i<100                 
        j = 0
        html =""
        While j<i
                html = html + "split string "
                j=j+1   
        Wend
                                
        Set mail = New Email()
        mail.Subject = "Test " + CStr(i)
        mail.HTML = html
        mail.Send("jake howlett")       
                
        i=i+5
Wend

What this does is send me 20 test emails. Each email is increasingly longer than the one before it and they all just repeat the words "split string" over and over.

The code to send the email is based on my Email class. All it does is create a multi-part MIME message. Nothing out of the ordinary. If you're using the MIME classes to send emails then this probably applies to you.

At some point in the loop the length of the message will get to such a size that something very worrying happens, as you can see below:

Notice the missing p?!

The Problem

From my investigations I've concluded the following:

If you use a 3rd party mail client (like Thunderbird) to download a multi-part HTML email from a mail file on a Domino server using POP3 then the POP3 server will remove the 655th character and put a line break in its place.

Looking at the very same email in the original mail file - using the Notes client - there's no missing character.

What I've also noticed is that it only removes the first 655th char. Not every subsequent 655th char in the whole string.

Obviously this can be very, very bad. At it's least worst, like in this example, it just looks like a typo. However, I've had numerous bug reports because it's broken the string inside an HTML tag, resulting in un-clickable links or -worse still - emails that just show raw HTML.

The problem seems only to occur when sending emails where the HTML content is made up of one very long string. I guess using very long strings is generally a bad idea in any case, but there's nothing actually wrong with it, and nothing half as wrong as the server removing characters.

The Solution

What we need to do is avoid very long lines of HTML code in the email. The obvious solution is to add line breaks in the HTML as you build it in your code.

Unfortunately, in my case, I have way too many instances of code sending HTML email to make it practical to go and add new line breaks in to each email. Instead, what I did was put a fail-safe in to the Email class which sends the email. At the point it adds the HTML to the email it adds a new line at every point an HTML tag is closed, like so:

Call stream.WriteText(Replace(Me.str_HTMLPart, ">", ">"+Chr(10)))

There's still a slight chance that there could be a long string that avoids this rule, but it's unlikely enough for me to feel happy this has resolved the issue for now.

Summary

So, you've been warned. If you're sending HTML emails to a Domino server, make sure you split the HTML string down in to sizeable chunks so that users who access their email via POP3 don't see broken HTML.

It all leaves me wondering why on earth the POP3 server would replace the 655th character in the first place. Assuming it does of course. My investigation wasn't exactly extensive but, from what I can tell, it definitely looks like it does. Why though? What's significant about 655? It's not like it's a base 2 number or anything.