"The contents of this message are corrupt. We cannot view this message."

Dear Lazyweb, what mailer emits this error message, and under what circumstances?

I occasionally get complaints from people who are subscribed to the weekly DNA Lounge mailing that this is all they see of the messages I send out. The messages are multipart/alternative with text/html and text/plain parts. The HTML part passes the W3C validator,* and all parts are 7 bit and have short lines. I'm as certain as I can be that the messages are valid.

I've heard of it from people using Earthlink, the AOL web-mail client, and once, Thunderbird. (The Thunderbird guy was an AOL user, and managed to forward back to me the message that he couldn't display in Thunderbird -- it was identical to the message I had sent, not mangled, and it displayed fine for me in Thunderbird.) Update: In hindsight, it's likely that all of these people were actually using Earthlink, but were confused.

Any ideas?

I'd write this off as "people who use AOL deserve what they get" but it seems more widespread than that, and I've been (very occasionally) getting these complaints for years. Telling them, "Beats me, report it as a bug to Earthlink" produces the predictable cricket-sounds.

If you want an example to test, subscribe to the list, there will be a new one sent out at 6pm on Tuesday. (Giving you a link to the raw HTML or a packed-up mult/alt probably wouldn't be a real test.)


* (And by "passes", I mean to say that the dozens of errors that it spews look like bullshit to me, which is the best that you can ever expect from that useless piece of crap.)


Update: Here we go again. Look, people, all of you who keep piping up with, "Maybe some software (that I don't know the name of) is doing this because it's trying to protect against viruses or something and is screwing up?" No shit! I got that far myself! Your theories about why some shitty software might fuck up this way don't help me. I'm asking what shitty software is doing this, so that I can figure out what it expects so that I can work around it. If all you have are vague guesses, rest assured that I have already formulated those myself.


Update 2: I tried to contact the one guy who seems to be responsible for Earthlink's mailer and he ignored me. I guess they don't care.


Update 3, March 2014: So 3+ years later, someone else emailed me to tell me that they had figured this out! Apparently Earthlink's MIME parser doesn't support *Content-Transfer-Encoding: 8bit, only quoted-printable. Because the year is still 1981 over in Earthlink-land. Turns out I still have a whopping 81 subscribers left on Earthlink, but I'm guessing they're not reading anyway, so I'm not gonna bother fixing it.

Tags: , , ,

52 Responses:

  1. Kiyoshi Aman says:

    I suspect some MTAs try to parse HTML in order to scan it for phishing or malware social-engineering attempts; if they're badly-written enough, the parsers will crash out, and presumably offer up that error message.

    • jwz says:

      That is a fascinating theory.

      • Thomas Lord says:

        It doesn't even have to be an MTA or anything you can clearly identify in the software stack you think you are using: people really do that kind of stuff at the IP level. For example, there are cellular networks that will filter the packets to your device, pick out and reconstruct HTTP traffic, figure out HTML from that, from that find certain of the pixmaps, and then kindly scale down the images and rewrite the packets before sending them on. I can help you find places to buy such boxes, if you are in the market.

    • Schuler Bob says:

      2nded. Not even a particular MTA, but a malware-scanning milter plugged into the site's MTA, will punt and return a message like this if it can't scan the payload for whatever reason.

  2. Jay Paroline says:

    If it's an effed MTA, wouldn't the message, when forwarded back to jwz, also be effed?

    • chabicht says:

      Maybe it is a plugin installed by some "Internet Security" / AV software? Filtering then runs on the client side, maybe before showing message contents but not affecting forwarded messages (which may sound stupid but who knows what's going on inside a Personal Firewall Software Engineer (TM)?).

    • gryazi says:

      This is also terribly unhelpfully helpful, since he refuses to help unless you contact him by means other than the email address provided to contact him.

  3. aveilleux says:

    You could try updating your HTML to, you know, validate. I'm seeing uppercase tags (deprecated), no DOCTYPE declaration (required for standards conformance) and no quoting of attributes (not standards-breaking, but it's good form). Instead of bitching about the validator, why don't you update the code that feeds into it? Some (admittedly retarded) email filters actually will complain about broken HTML.

    • Art Delano says:

      I regularly deal with hosted mail subscription services that auto-translate tags into uppercase, strip quotes around attribute values, and overwrite or strip HTTP, HEAD and BODY containers. The mailshoots go fine. I wouldn't rule out petty inconsistencies like casing, but I suspect they're not the problem.

    • ix says:

      The rules are slightly different in email land. Some email clients actually require broken HTML. It's likely to look more like HTML 3.2 (admittedly with more CSS) than HTML 4 or (gasp) xhtml. CSS will work but half-broken. Doctype is just unnecessary, really.

      Here's a good general guide.

      I assume jwz is testing in the validator to find regular old stuff like unmatched tags, but it's strictly useless for any other email related testing. Fixing those errors you list are very unlikely to actually help, unless you can produce a particular email client that you're sure will fail on it.

    • jwz says:

      Updating my HTML to "you know, validate" would also mean updating it to, "you know, not contain Youtube videos", since the validator objects to things like, you know, the PARAM tag.

      You can't put a doctype in an HTML email, because most readers have wrapped their own HEAD and BODY around your content before they get that far. And the validator isn't even complaining about capitalization, only you are.

      Go troll somewhere else. You don't know what you're talking about.

      • aveilleux says:

        Pardon me for keeping up with Web standards. Tag capitalization has been against the standards since, Idunno, 2000? The reason the validator isn't complaining about it is because you're using the Transitional doctype, which is basically a free-for-all. If it's ever existed as an HTML tag in Netscape or IE, it's in the Transitional definition.

        The validator will accept my test pages that have embedded YouTube videos (XHTML 2.0 and HTML 4.01 Strict), so I really have no idea what you're saying there.

        • http://me.yahoo.com/leherrer says:

          He is not validating an actual web page, you know.

        • Yeah, we're pretty standards-heavy where I work, but when we do the occasional marketing email for someone, we've gotta write all kinds of crazy shit for it to (barely) work in even most clients.

        • Breton says:

          You're not keeping up with standards very well. It's 2011, not 2000. Tag capitalisation is only against the *xml* standard, and xml is pretty dead. Unless you're a Java developer, in which case, Java is also pretty dead. There may still be zillions of people using these technologies, but the same is true of cobol and fortran. They are no longer the new hotness that all the cool kids want to use. Just more bullshit to grudgingly work around.

          And as others have pointed out, email is a different game, the clients haven't been keeping pace with the browsers. In addition, there's all sorts of random security measures (such as the one that this whole post is about) that annoyingly cause problems. There is no HTML email standard. Everyone just sorta does whatever. It's nuts.

  4. Hank says:

    Hi There,
    I had this exact same problem with Earthlink and AOL with notifications that my site sends out. They emails are brain-dead-simple HTML (although I did not validate them), they follow all the MIME rules, etc. I've tried for two weeks to resolve this problem for these users... and I've never been able to fix it. I've also had no luck in trying to find out from Earthlink or AOL exactly *why* the messages are failing.... so I took the brute force approach:

    if (preg_match("(aol.com|peoplepc.com|netscape.net|earthlink.net)",$domain)) $text_only=1;

    ... that is to say that I convert the emails to text only and send them that. Sure, they complain that the links aren't clickable, but at least they can read the emails sent. I'm done trying to fix AOL and Earthlink's problems. If you ever find a solution to this, I'd love to hear about it. Thanks.

    -Hank
    Where's George?

  5. Unrelated WordPress niggle: in the last couple of days, this blog has started provoking Safari to ask me if I want to accept your self-signed SSL cert every time I visit. It's not clear to me what part of the page is doing that, since as far as I can tell most of it is plain-HTTP, but it's annoying.

    Possibly this, and the ensuing JQuery DOM-whacking?

    var ajax_url = 'https://www.jwz.org/blog/wp-admin/admin-ajax.php';

    • jwz says:

      That is annoying.

      I thought that people-who-are-not-me never needed to load URLs under the wp-admin directory. I guess that's not the case.

    • jwz says:

      I think I fixed it. Did I? (If things are working right, shouldn't ever see the cert warning, because in normal usage you shouldn't ever be forced to load a https URL from jwz.org.)

      • No, it's still doing it, and I still see the relevant script element in the page if I go looking. Also, the comment notification emails have mysteriously changed the first sentence to "Unrelated jwz.org niggle". Welcome to the future.

        • jwz says:

          How about now? (Empty your cache first.)

          Don't understand what you're saying about the first sentence.

          • It's still doing it. Oh well; your content is much more interesting than the mechanism by which it's delivered, so don't waste too much energy on this.

            The first sentence of my original comment begins with "Unrelated WordPress niggle", but appears in the emails telling me you've replied as "Unrelated jwz.org niggle". *shrug*

            • Gah, I can't figure out where it's getting the https URL for that fucking ajax URL from. When I view source, I don't see it. Do you?

              I know you don't think that dialog is a big deal, but I do, so I really want to make it go away.

              I see where the s/WordPress/jwz.org/ bullshit is coming from, and it's a result of my attempt to de-brand things that is sadly hard to avoid (I didn't want the mail to say "This message sent by WordPress"!) Don't say the word WordPress, I guess...

              • Tom says:

                ajax_url is a red herring.

                The problem is caused by a request for https://www.jwz.org/blog/?xd_receiver=1, which looks like some async Facebook bullshit. You're specifying the non-SSL version of this URL so it's unclear why it's loading the SSL version.

              • hattifattener says:

                it's all good until you try to talk to people from the village of Swordpressthorpe

    • jwz says:

      FYI, the problem I was having here is that I want to enforce SSL access for the admin area, but prohibit SSL access for the non-admin area, and WP conspires to make that difficult by mixing and matching what's what. You'd think that non-admins would never need to load URLs out of wp-admin/, and admins would never need to load secure URLs out of wp-content/, but nooooo...

      Also admin_url() is weird, so I had to change several calls to it from admin_url("...") to admin_url("...", (is_ssl() ? "https" : "http")).

      My current mod_rewrite rules (getting hairier by the day) are:

        # These URLs require SSL.  All others require non-SSL.
        RewriteRule ^wp-(admin|login|register|signup) - [E=NEEDSSL:1]
      
        # This URL can be either SSL or non-SSL.  Leave it alone.
        RewriteRule ^wp-admin/admin-ajax\.php$ - [QSA,L]
      
        # This Facebook query-string can be either SSL or non-SSL.  Leave it alone.
        RewriteCond %{QUERY_STRING} (^xd_receiver) [NC]
        RewriteRule .? - [QSA,L]
      
        # NEEDSSL && !SSL: turn it on.
        RewriteCond %{HTTPS} !=on [NC]
        RewriteCond %{ENV:NEEDSSL} =1
        RewriteRule .? https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]
      
        # SSL && !NEEDSSL: turn it off.
        RewriteCond %{HTTPS} =on [NC]
        RewriteCond %{ENV:NEEDSSL} !=1
        RewriteRule .? http://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]
      
      • It looks like that finally fixed it. Safari's stopped telling me about your certificate and I no longer see that URL in the page source anywhere, either here or on other pages. Thanks, dude!

      • Jeffrey Paul says:

        Is there a non-curmudgeonny reason you are trying to serve ANY content without SSL?

        • jwz says:

          Does "I don't feel like paying the $400/year Verisign Tax for you people" count as non-curmudgeonny?

          • Phil says:

            The current answer to that (perfectly reasonable objection) is http://www.startssl.com/ : One personal cert + one server cert for free. The CA is in all the major browsers & email clients, including Microsoft ones.

            • Phil says:

              NB: The CA is in the clients, but the intermediate certs between the CA and the cert they give you aren't, so you have to configure your servers to feed them to the client as well. This is easy with Apache (just a config option to point to the intermediate cert) and a pain in the neck with exim4 (you have to bundle the intermediate cert in the same file as the server cert & get them in the right order or the clients complain bitterly).

            • jwz says:

              What's the catch?

              • Phil says:

                So far I haven't found one!

                Obviously they'd like you to buy more & higher grade certificates from them, but so far the free cert they gave me has been catch free.

                Poke https://kantaka.co.uk/ & the smtp server at imap.kantaka.co.uk with "openssl s_client -starttls smtp -crlf -connect imap.kantaka.co.uk:25" to see it in action. (The server cert will certify a top level domain & one subdomain: both the mail server & the web server are using the same certificate.)

                You have to renew it every year, but the same goes for the paid certs, so no loss there.

                • Phil says:

                  nb. add -CAfile or -CApath to that openssl invocation to point it to wherever your CA certificates are.

  6. Phillip Remaker says:

    FWIW: The most recent email renders correctly in both the AOL classic webmail and beta AOL Phoenix Webmail without complaint in Firefox 3.6.12 and IE 8, and in GMAIL when fetched from AOL via IMAP.

    • Well, these important AOL details are something that both pleases me, and makes me feel like a worse person for the knowing of it.

      So... thanks?

  7. Kyzer says:

    Person forwarding error message using same mailer that gave it:

    http://groups.yahoo.com/group/bodymodstudy/message/64?source=1&var=1

    Gotcha.

    X-Mailer: Earthlink Zoo Mail 1.0

    My wild-assed guess is that this is Earthlink's webmail system (seen in an apple support discussion when googling for "Earthlink Zoo Mail"). The Earthlink people still maintain their webmail system: http://blogs.earthlink.net/webmail/ - why not ask them?

  8. Al says:

    I've never seen this ever, and I've been sending gobs of scripted emails like this for years. You're going to hate that I'm offering a suggestion without knowing what MTA is to blame -- but even without that info, I rather suspect that if you build multipart-MIME emails with both a text and an HTML part -- and you build them in a way very similar to how Thunderbird builds them when sending a rich-text email from Thunderbird -- you will address the issue. I don't go the full monty and bother with quoted-printable, but I otherwise use Thunderbird's output as my guide, and it tends to solve all other woes. And I am very lazy in my HTML -- I'm sure I've accidentally used raw 8 bit chars, don't properly set all the headers all the time, don't validate my HTML. And even with that, I've NEVER seen what you're running into, in years of sending millions of emails.

  9. nightbird says:

    Your upcoming events posts give me the error message in the Earthlink web mail site. When it is later POPed by Thunderbird it reads fine both as HTML and as "Plain Text." (Assuming by "reads fine" you want the HTML to display black text and blue links on a white background.)

    Your posts are the only ones that give me this error. OTOH I generally use Thunderbird and not Earthlink's site to read mail so it's not my problem.

    • jwz says:

      Well, I sent a message to the one guy linked above who seems to know anything about Earthlink's mail setup, and he hasn't written back.

      Not everyone who complained about this said they were using Earthlink, though, which makes me suspect that it's some 3rd party piece of shit that both Earthlink and other sites have installed.

    • jwz says:

      If you (or anyone who can reproduce this) would like to try to cutting the message in half repeatedly and re-sending it to yourself until you find the point at which it goes from "fail" to "win", that would be awesome... (I could probably sign up for Earthlink myself just to diagnose this, but, well, I don't wanna.)

  10. Nate says:

    While this is probably not the exact problem your customer has, you may encounter it with others. AVG anti-virus does some rewriting of messages that screws up Outlook. I had complaints from a customer when sending a normal attachment in Thunderbird (mime/multipart) that they couldn't read the entire message.

    http://beyondteck.blogspot.com/2006/05/blank-email-messages-in-microsoft.html