Minification and Deliverability

[pleeflang]

Hi,

Sorry all this isn't 100% Marketo related but I'm reaching out to the Marketo community for some help cause it always pulls through. We use Marketo on the b2b side and Iterable on our b2c side. Iterable mimifies our emails and are executed through mailgun. Our emails for a particular population have not been performing well and I question the deliverabilty. We mostly have emailed a client population and are whitelisted on their email server but the particular population that isn't performing well has personal email addresses where we can't be whitelisted. 

We use Everest for deliverability and sent some tests and the Majority have performed terribly, scoring between 13% and 24% with 75% to 80% missing. We've had some that have scored in the 90s and found a common trend in character counts.

I ran a character count on some of the emails and found the ones that performed better were around 40,000 characters on one line and the others had > 60,000 characters per line. I read on a community post in litmus that says you should stick to 800 characters per line and we're way over. The majority of the emails we send are on the longer side > 60,000 and those we don't score well. 

I set up google postmaster to see if it would give me some extra insight into what was happening. I feel like its not giving me the data and only really shows certain errors and spam triggered emails, IP and domain reputation, and whatnot, when I want to measure the volume that is making it through. We have a private IP and email domain that all score well but deliverablity is doo doo. 

Any thoughts?

[SanfordWhiteman]

Let’s hone in on your definitions a bit.

Are you saying that Iterable is using CTE: 8-bit (that is, not quoted-printable or any other 7-bit line-oriented encoding) and running 50,000 UTF-8 bytes on a single line even if the source content had line breaks?

[pleeflang]

Yes, I thought Mimification was more used for Web and not email.  Her is a sample https://go.swordhealth.com/rs/675-GJP-011/images/iterablesample.html 

[SanfordWhiteman]

Do you actually mean to say MINification (whitespace compression and other optimization) , not MIMEification (i.e. creating SMTP/MIME parts)?

[pleeflang]

yeah Minification. sorry I didn't catch that difference. In all my time I've never seen this done for emails. Any thoughts? 

[SanfordWhiteman · Accepted solution]

In an environment with no other restrictions, you can put an entire HTML page (in UTF-8) all on one line, since line breaks are largely insignificant* in HTML and HTTP isn’t a line-based protocol. Such is the case with a web page: everything’s safe between a browser and a webserver and removing line breaks saves a lot of bytes.

However, SMTP is not such an environment because it applies additional restrictions.

First is that a standard SMTP DATA line** can’t be more than 998 characters (and is usually broken at 76 chars for ultra-legacy reasons). Some servers are nevertheless forgiving about this. Other servers are rightly strict, because allowing overlong lines just encourages senders to think they’re okay everywhere.

Second is that SMTP involves not just different mailserver vendors across recipients, but may mean multiple server “hops” for a single recipient. Those hops can have varying feature levels. One hop might not be 8-bit clean, so data may need to be translated between 8-bit and 7-bit, and so on. The more translations need to be done, the more likely data will be corrupted (especially if it was originally standards-invalid).

Taken together, the conclusion is the data that’s put on the wire over SMTP will have line breaks.

But note: that doesn’t mean you can’t remove line breaks from HTML first, and then break the one-liner result into 76-byte or 998-byte lines — that’s how you optimize the number of breaks while still being standards-valid. So you can have an editor window in which you don’t use any line breaks, but when the text is fed into the SMTP layer, it gets encoded and line-broken properly.

If you’re observing that the actual text sent using SMTP DATA has lines that are 10,000 bytes long, that’s wrong and a mail scanner that looks for anomalies would be right to pick up on that. I spent a long time in the spamfighting world and one thing we look for is a message that seems produced by an amateur mail app (i.e. spambot) because it doesn’t obey standards. This might be surprising because you’d think a spamware author would be able to read and implement standards properly... but in practice, many are not (shall we say) full stack developers even if they’re good hackers!

* either ignored or equivalent to a single space, except for in a <pre>

** i.e. not a BINARYMIME section, which isn’t line-based, but you can’t rely on support for BINARYMIME