Images in Email: Embedded vs. Referenced

One of the greatest things about email is that you can present your information to a targeted audience and you can spend time on making the emails attractive enough to capture attention. One of the elements in these email is graphics, and these elements can be an awesome addition or they can be the death of your email. As in all things, there is a balance, and we will discuss some of them.

Number of Images - When embedding images, each image in the email becomes an attachment to the email. Because of this, each email will have to be read from the disk, encoded, then appended onto the email message and this adds to the email's overall size too. If you have 10 images, then it has to do this 10 times. I have seen some emails with 100 embedded images in them. Creating the email with lots of embedded images is one thing, but the people receiving the emails will have to able to read them too and they might have limitations themselves. I tell people if you start exceeding 20 embedded images in emails then you are pushing it. Yes, the technology at both ends will handle it, but it is a matter of practicality.

Size of Images - We have had some clients call and say their emails are going out so slow. After analyzing it we will find they included a single embedded image that was 4 megabytes. Now it is possible to send and receive this size of email, but as the email size goes up, the amount of time its takes to send increases too. Other things to consider is the recipient's email system may reject these email sizes, or the recipient may still be on a dial-up or slow DSL and will not appreciate your email taking 30 minutes to load. This is a huge consideration especially for international email lists. So, consider this, you may have an image that is 4 megabytes because it is super high resolution. For an email, you are not going to need that resolution or size, so open the image in an image editor and reduce its size so it fits in the email space nicely. You will find these images will reduce in the the 10-90KB range and now that is a good size to send.

All Email Clients Not Created Equal - There are several email clients that will just not show embedded images. May portable devices are like that. When you create your email, test it will several different email clients like gmail, yahoo, and hotmail. Also, check portable devices like Androids, iPhones, and iPad to make sure the email looks like you intended.

Having to post images to website- An alternative to embedding images it to post the images to a website somewhere and reference these images in the email. The advantages to this is that your email is very small and will deliver quickly. Images from webservers load very quickly, much faster than an email system. The disadvantages of this is that your email is not a complete unit on it's own and the recipient will have to be on the internet to see the entire content of the message. This is usually not a problem though because you are usually on the internet when reading email anyway. Also, you will have to coordinate the availability of the images being on the website for the email's use.

The Making of Campaign Enterprise 12

After years of development and a complete re-write, Campaign Enterprise version is close to completion. We have had many inquires about what will be included in the new release. It might be good first to show how the software has developed over time.

Back in the early 90's, Arial Software was created just about when the internet was gaining steam. The first product we created was a desktop emailing system. It was basically a glorified Microsoft Outlook, had some merging capabilities, but nothing like SPAM or unsubscribes existed back then. As the internet changed and SPAMing became a reality, the software change to accommodate this. Then Campaign Enterprise was created which was the first web-based product we had with a built in webserver. This webserver was pretty simple but there was no configuration required and back then IIS was very difficult to configure and not get hacked. Campaign Enterprise continued to accommodate for new SPAM rules, new online editors, new operating systems, and new databases. During this time the same code has been used and features like multi-threading, SSL security, and other webserver system were added. The things we created ourselves were now becoming available in the .NET programming world and though our systems were stable, it was time to move the system to a new language and platform.

For the past year we have been rewriting Campaign Enterprise from the ground-up. Campaign Enterprise is now completely written in the .NET framework, supports true multi-threading managed by the OS, and the platform for the webserver is now IIS (Microsoft's Internet Information Service). Campaign Enterprise now works as two separate systems working in harmony. The webserver aspect of the product, used for campaign administration, conversion event resolution, views-as-webspage function, and unsubscribe functions is now all IIS driven. Now, you will have control over all aspects of how the products works, like security, SSL certificates for HTTPS functions, NTML user authentication, and everything else IIS offers.

Also, the back-end database for Campaign Enterprise will now be based on Microsoft's SQL server. Campaign Enterprise will include a version of SQL server or you can use your own existing SQL server by creating the appropriate database volume.

There is much more to come, but below is a short-list of the new capabilities of Campaign Enterprise version 12:

• The system completely rewritten in a modern language (.net) that supports today's OSs and multi-threading

• The web server portion works in Windows IIS which offers a ton of flexibly.

• Email sending speeds have been dramatically increased

• The user interface is more intuitive to sending email

• You can send from multiple lists at the same time

• There is a built-in POP server so all bounce handing is done internally and you don't have to establish bounce POP accounts for each campaign as before

• You can create "Client" areas, each with their own users and campaigns separate from all other Clients (different clients, departments, etc.)

• You can create and maintain built-in Email Lists with importing capabilities

• The backend database is MS SQL Server. You can use the free version of MS SQL or use an instance of your own SQL server

• Email sending is done using multiple sending threads instead of a singular sending thread

• Since we are using IIS for the web server all SSL certificates for communicating in HTTPS are support

• Windows user login ability (NTLM) allows you to choose to use your Windows login context to log into Campaign Enterprise

• View email as a webpage capability

• Graphics that are referenced in the email you send can be upload through the interface and used by the emails when they are viewed

• Higher performance conversion tracking due to the IIS server and MS SQL server

• More reporting capabilities with the combination of MS SQL server table and better recording structure

• Able to submit campaign initiation from outside of Campaign Enterprise (API)

Identifying Performance Bottlenecks

There are many elements that are involved in email distribution that can affect performance. When you have to send out a few thousand emails performance does not really matter as much, but if you are in the ten's or hundred's of thousands then performance is crucial. The flow of an email distribution system is:

SQL or file-based Database with email addresses and other info (SQL Server, Access, Oracle, etc.)

Email merging and sending software (Campaign Enterprise)

Mail Transport system (SMTP) like PowerMTA, Ironport, etc.

Bottlenecks can occur in these systems, as a result of the merges within an email itself, or depending on how these systems are placed in a network, the connections between them. The way to diagnose this is to start from the back and work your way up front.

Checking the MTA

The #1 bottleneck we have found historically is the MTA. Campaign can send emails faster but it is wait for the MTA to accept the emails. In order to find out if this is the bottleneck you will need to send the emails to a different MTA that will accept emails at an extreme speed. Then, if the sending speed increases due to this switch, then you know it is either the MTA or the connection to the MTA system. The simplest way to do this in Campaign Enterprise is to:

1. Create an SMTP Connection that sends the emails to a folder (EML files) instead of the MTA. Do do this, after logging in as an administrator, go the the Administrator link, choose SMTP Connections, then create a new SMTP connection and select EML Files, and set a scratch folder on a disk the EML files can be sent to.

2. Change your Campaign's sending SMTP setting to this new EML files setting

3. Run the campaign. You can stop it after a few thousand emails or 1 minute, it should be sufficient to get a performance

4. Go to the reports for that campaign and see what your performance is in the Overall Report

If your speed increase after this test, then you can assume the issue is your MTA or the path to it and that should be addressed. Many MTAs are busy doing other things, they could have throttling agents in place for mass-mailings, etc. So if this happens to be the case, then there is plenty to check out. Sometimes when the MTA is on the same box as the database and the Campaign Enterprise, it is true that communications between these system can be really fast, but it may end up being slower overall because the computer has to manage all these processes even with multiple cores.

Writebacks During Send

If you are writing-back to the database after each email goes out, then you should probably disable this code for the test above if there is no improvement. It is possible though this write-back activity could be the bottleneck, so if you can leave it in for this test and reset the data after you run the campaign that would be best.

Merge Field Performance

If you have a lot of merge fields in the message, especially if it is a large message, then that can cause a bottleneck. Remove all the merges from the email and send a test Campaign to the EML files.

Email Size

If your performance is going down sometimes a your emails may be unknowingly getting bigger and require more transmission time. Reduce your email to a simple 1 line email and test again using the EML files setting. If the performance speeds up this may be the problem.

Embedded Images

If you have embedded images in your email, that can slow down transmission of the emails. Also Campaign Enterprise always does a scan for embedded images in an email. If you are not using embedded images you can go to the Miscellaneous tab for the Campaign and check the box to ignore the embedded images scan.

Your Database

If extreme rare cases your database may be the issue. If none of the steps above help performance then it may be your SQL server or single database file. Best way to test this is just to keep dumbing-down the SQL statement you are using until it is very simple. Usually single database files are very fast, like MS Access, but SQL servers can be busy or on a different computer on a busy network. We found many times an SQL server really slows down when batch processes are being done on them, like backups or mass data updates.

If you find that none of these are helping, we can definitely help further by logging into you system for an analysis.