Thread

Hi sorry this is a newby question:

I’ve just sent a formatted email to my inbox, duplicated to myself at work. It’s got plain text and HTML MIME parts, and embedded JPEGS, referenced in the form SRC=“CID:imageobjectname”.

My own copy arrived back here fine, but 20mins later, it hasn’t yet turned up in my .(JavaScript must be enabled to view this email address) inbox. I assume it’s being blocked for some reason, so do I need to delete the plain text alternative MIME part?

Any assistance would be appreciated - I did try a forum search, but couldn’t find anything relevant.

Thanks,

Simon.

Hey Simon,

An email will not be added to your inbox for any of the following circumstances:

  * Your email has attachments
  * The content of the email is blank
  * The content of the email does not pass our content filters

You mentioned that you are embedding JPGS, are you sure your system isn’t inserting absolute references to those images?  When you received the test email, did it come with attachments?

I don’t understand what you mean by “attachments”

Below is the structure, with the actual content omitted for brevity. There are two text blocks: text/plain and text/html, then three images, base64-encoded jpegs, per usual, referenced in the HTML part of the message. There’s nothing otherwise “attached” The content would be where the vertical ellipsis is:

It’s generated by a Microsoft library function (within the dotnet framework), so it may be that MS aren’t constructing it correctly, but since they started HTML emails in the first place, one has to assume…

Thoughts appreciated.

S.

PS: We know that 90% of our recipients block externally referenced images in their mail readers, hence the embedding of images rather than hosting. It’s the inconsistency of mail readers in this regard that I’m trying to understand better!

Simon,

Unfortunately we don’t allow embedded images in our acid test due to security reasons, which is why your email is not making it to the inbox.

First off: This morning I think I have found what seems to be a bug in your system (or something else I don’t understand). My attempt today to send to a test message to my inbox resulted in this mailserver ‘verbose mode’ response:

However, the web interface “dashboard” indicates there is no mail in the inbox.

Meanwhile, back at my original problem, you said this:

Michelle Klann - 10 March 2011 03:03 PM

Simon,

Unfortunately we don’t allow embedded images in our acid test due to security reasons, which is why your email is not making it to the inbox.

Then you should say so, unambiguously on your web site. The term ‘Attachment’ is ill-defined and misleading.

Incidentally, we have re-coded our app. to declare images as MIME types ‘image/jpeg’ amd ‘image/png’. This now displays correctly on the iPhone IV mail client.

I assume from your response above that I cannot test such messages via your system, either. For clarity, please can you confirm:

1. Which, if any, multipart MIME structures/declarations can be tested. For example is

acceptable (for messages with a text alternative to HTML)?

2. that absolutely no images of any sort accompanying text/html within an email can be submitted, no matter how they are identified in the various MIME blocks?

Obviously if your answers are as I expect, this severely limits the usefulness of your tests for my purposes.

I await your reply with interest.

S.

Greetings Simon, we will look into the My Inbox response that you received. This is the first time we have been informed of that error message.

To answer your questions:

1) You can send an email with a text alternative to our system, but since all of the clients we support in our test support HTML the text alternative will not be displayed.

2) No embedded images are supported in our system, regardless of mime-type. Again we do not allow them for security purposes, if we allowed them someone could potentially release malicious code on our servers.

We will be sure to update the My Inbox page to mention that embedded images are not allowed in emails sent to our system. I apologize for the confusion.

Please let us know if you have any other questions.

John Thies - 15 March 2011 08:24 AM

Greetings Simon, we will look into the My Inbox response that you received. This is the first time we have been informed of that error message.

To answer your questions:

1) You can send an email with a text alternative to our system, but since all of the clients we support in our test support HTML the text alternative will not be displayed.

Mornin’ John,

Thanks for the early-bird response!

The text-alternative thing is actually fine, as I can test that thoroughly locally. We always declare image sizes too, within the HTML, so I can probably get a representative view of the message.

2) No embedded images are supported in our system, regardless of mime-type. Again we do not allow them for security purposes, if we allowed them someone could potentially release malicious code on our servers.

Obviously security is potentially an issue, although exploits involving JPEG, GIF and PNG are very, very rare.

Given three environmental factors,

1. that the vast majority of email recipients in commercial organisations are unable to collect images from an external server (or have that functionality disabled by their administrators), and

2. that the nature of effective email campaigns means that either embedded or hosted, the smallest images practical are used, and

3. that the well-understood (and equally well-disliked) use of the MS-Word HTML rendering engine in the two most recent versions of Outlook means that email with embedded images, per Outlook, has a much higher chance of being presented correctly to an Outlook-using recipient (and it reduces the spam-score significantly, compared to hosting),

I’d thus suggest there is still a powerful case for enabling testing of messages with embedded images. Even with the necessary size and filetype constraints, it would be very useful.

Obviously, if the client’s campaign is aimed at private individuals, this has less importance, but, for people like ourselves (focused on B2B activities), there is little choice but to embed images.

Obviously too, I can quickly work around this restriction by hosting the images, but it’s not then doing the fundamental thing: testing the actual email I will be sending.

So I’d strongly urge you to consider it. You might even charge a premium price for such a service

Regards,

S.

+1 to supporting embedded images.

We use embedded images to get around external image blocking.

Not supporting this makes your service much less effective for us.

Any chance you guys might revisit this?

+1 for embedded images.

This service is practically useless to our organization without being able to fully test the email presentation.

Please reconsider supporting this feature.