I have a test program that logs the users answers and grade to a log file. I also have it email off this in a nicely formatted html email to the administrator of the tests.
For the most part, this system works. But strangley I've noticed that different email clients are removing portions of the code. It's a table, so a lot of the code is very repetitive, and the sections that get removed are the same every time for each email client (outlook and gmail are the ones I've tested). So for example, if I have a section of the table:
<tr><td style="background:#a66;text-align:center">This is the answer</td></tr>
Then it may come out as:
<tr><td style="backgrouter">This is the answer</td></tr>
And I can't find any correlation between where it does this in each file. Sometimes its near the end, sometimes near the beginning. In some cases, if the test was particularly long, it won't even finish the email.
I have my php outputting the same exact html to a log file on the server, and that always comes out perfect.
What's going on? How do I fix it?
I think this is because of the 998 characters per line limitation on MIME Email.
For more details, you can see below posts:
Reasoning behing 76 being the line length limit for MIME sections, as defined by RFC 2045? (See answer by appleleaf)
HTML safe wrapping of long lines
My solution is to add "\r\n" between HTML tags so it won't exceed 998 characters per line. This works for me.
The one thing I can think to try is to append an !important to the each CSS statement.
<td style="background:#a66 !important;text-align:center !important">
Oh, and just noticed you are missing a closing ;.
That is weird!
Ok, firstly, have you tried spacing and terminating all the styles? eg:
<tr><td style="background-color: #aa6666; text-align: center;">
Secondly, it may be some strange HTML interpretation that Gmail is picking up on although I can't think of a reason for this to happen (eg. style names or reserved function names etc).
Otherwise, I'm stumped. I've only ever seen this happen with yahoo mail, where the HTML in an email broke the yahoo mail layout...
I'd be tempted to use css classes and style them inside a style tag. I've never seen them break.
I am afraid your problem has a deeper problem.
Those clients have some obscure way of processing data, and end up repeatably sent mails from same email dress to render it as it was a quote from some other mail.
I would advise you to check the html consistency of the mails, and to read up suported html for emails.
Also make sure that your email header is saying it is a html formatted email and not plain text. Formatting in the header is also important i would command utf8
Related
I've noticed that when you forward an html email from Gmail (not sure about other providers), the html structure changes in the process. The forwarded html loses all the ids declared inside the original html, also some other 'cleaning' happens on the html too.
Can anybody explain why this happens or if it's possible to avoid? Or is it totally dependent on the smtp provider?
I have an app that monitors emails on a specific inbox and tries to parses it, but as I said when the user forwards his email to this inbox (from gmail), the email html structure gets cleaned and my code can no longer parse the html because a lot of the ids are gone.
Due to this, I have to find a new way to parse what I require from the email, like using regular expressions on the plaintext section of the MIME message.
I've searched about this matter and I couldn't find any single piece of information.
Gmail strips head tag and Ids and classes on pre-processor. That means when you forward or reply, to gmail, these items never existed so are not included on reply.
As Gmail removes head tag, id, classes and more, the best way is to use inline CSS style.
Tip: An inline style loses many of the advantages of a style sheet (by mixing content with presentation). Use this method sparingly.
In our internal CRM we have a simple html input textarea where you can leave notes and messages. We later use this information to email this, only since that email is in HTML the formating is all wrong.
So if for example I have the following in my MYSQL table:
This is a test message!
Some line
Some more lines
If we later email this it comes out as:
This is a test message! Some line Some more lines
This is obviously not wanted but I don't want to add some complicated WYSIWYG editor to our CRM. Can I allow line-breaks? If so, how?
I don't want to use <pre></pre> tags because I believe it is not supported in all email clients (I could be wrong).
You could use text/plain header, if you don't intend on using any HTML tags in the message. (That would mean no colors, no links, and no text formatting).
You could also make a quick and dirty solution to replace all \ns in your text to <br>\n.
The problem is that html renders all whitespace as single spaces. If you look at the source of the email once it's received, I'll bet the newlines will be there (if they're not, then the problem is on the email generation side).
<pre></pre> is the simplest thing you can do, I think.
A basic solution would be to replace new lines with <br>s.
A smarter one would give special consideration to multiple line breaks (e.g. treating /\n\s*\n/ as a point to end a paragraph and start a new one (</p><p>)).
The specifics would depend on the language you are using to generate the email from the MySQL data. You might want to consider something like a Markdown parser.
You can send emails in two flavours: html and plain text. In Html, line-breaks are not processed (just like in your browser). Looks like this is what you are doing here.
Two solutions: either you send emails in plain text, or you change line-breaks to <br>.
Assuming PHP is in the mix, there's the nl2br() function. Otherwise, rolling your own won't be hard.
The root of this issue is that browsers (mail clients can either use embedded browsers for rendering - Outlook for example - or behave like browsers) will take any amount of whitespace/new line/carriage returns/etc outside of tags in HTML and render them as a single whitespace. This is so you can do things like indent your markup and still have it look sane in the browser.
You will have to insert markup in order to control the rendering as has been has suggested: convert newlines to <br> or <p> tags and so on, much like cms WYSIWYG editors do. Either that or chose a different format for your emails.
We generate quite large HTML emails - so hit the Outlook Email Client problem/software flaw where it decides to stick page breaks into the email if it thinks it's reached an A4 number of characters. [This is due to the Outlook Email Client using the Word engine to render it's HTML.]
This would not be a problem to us except that
It may occur in the middle of some HTML.
It's destructive.
Example of 1: If you have some html
<img src="http://
you may get
><img PAGE BREAK HERE
src="http://
Example of 2: If you have some html
<img src="http://
you may get
>**PAGE BREAK HERE** img src="http://
Which has destroyed the "<" of the "<img" tag.
Our emails are dynamic so each one may have this page break issue at different points in each email. :o( We try to get around it with 'sacrificial' areas of blank spaces to absord the page breaks - but this system starts to break down as our emails are become more complex over time.
Example of a potential work-around that did not work for us:
Mike The Coder - Page Break Before Always
Post that mentions issues in this area:
Horizontal Spacing Issues in Outlook 2007 and 2010
Do people know of other ways of trying to stop this or of working around it in the Outlook email client?
This article discusses a possible fix, but it would require a registry edit:
http://www.msofficeforums.com/outlook/6277-prevent-outlook-adding-line-breaks.html
Here is another article that has a workaround that could work for you possibly, without having to edit the registry:
http://answers.microsoft.com/en-us/office/forum/office_2010-outlook/line-break-in-plain-text-emails-in-outlook-2010/11d69847-f576-4002-b2fb-67bc59a69ce6?tab=AllReplies&tm=1329162544193
I got some auto generated HMLT code working. Made sure it is correctly parsed by http://validator.w3.org/, and it is a working HTML4.01 Strict.
Now, when I embed this code in a email and send it to gmail, the result is quite adverse (messes up the formatting).
The code is quite long, and apparently only happens when it has such size. This tells me two things:
not worth putting a code snippet here
it is probably some conflicting tag, but still considered valid the parser
Would you guys know of any tool even more strict to validate my HTML? Maybe even something specific for gmail?
Or maybe, just some pro tip on what usually screws the code for gmail.
ps.: the code, although is long, is also quite simple, only a few tables and styles - I took some care in making sure used only "email friendly" tags and formats.
Did you say styles? Oh, boy! Email clients are all doing things differently and even if you get it working for GMail, it may not work for Yahoo.
You may want to look at something like Email CSS guide to start, but really you also want to use some of the Inbox Analysis services (e.g. Inbox Inspector from MailChimp) to get a better picture.
I haven't done this myself (yet), but I have seen mentioned over and over that this is one area you can lose your hair over.
You have to code like its 1999 and not worry about being so tied to conformity to HTML.
Unfortunately valid HTML just doesn't work for some (most) email clients. Even Gmail will strip or ignore things probably for security reasons. The best bet for an email is basically HTML 3. Some inline styles for fonts. I know that <p> tags break in Gmail, and in general colspan and rowspan won't work as intended and you have to use nested tables. Those are just a few things I can think of off the top of my head.
All the answers here helped, but the actual problem was elsewhere.
The problem was In the HTML as I thought, but not exactly in my HTML.
Turns out the the email client will wrap lines too big before handling it to render, regardless if it is HTML code or whatever, more exactly, breaking tags in the middle - that explain why it was happening only when the report reached a certain length.
What tipped me that was when I looked at the code generated by MailChimp (suggested by Alexandre Rafalovitch) and noticed it was formatted as quoted-printable, cropped at exactly 75chars for every line.
After that was easy enough to do the same in my own code generator. Well, actually, I didn't even format as quoted-printable, only made sure it would wrap too long lines by itself.
Apart from that, for all I can tell, a HTML 4.01 Strict code will work pretty much fine in a Gmail client.
Hope it helps post-1999 generations.
cheers.
Is there some sort of formatting protocol for html email? We have an automated system that sends reports via email, when I look at the source I see them delimited by line length with an "=" breaking the line. That is, I get something like :
<html><body>some text some text some text some=
some text some text some text some text som<ta=
ble>some text some text some text some text <t=
r><td...
Does anyone have any more information on what this is?
You have to send the message as multi-part MIME. Best practices are:
Always send an HTML and a pure text version this way for mail clients that don't support HTML or some people just turn off HTML in emails (there are security/spam isssues with images although a lot of clients won't auto-download images from non-trusted sites anyway);
Images can be included in the message instead of as straight links. Straight links save on bandwidth but are a spam or even security issue (eg Internet Explorer had a buffer overrun bug with PNG images). Embedded images are references with cid values; and
Only use the most basic HTML. Browser HTML support varies from the primitive to the bizarre. When I looked into doing this we just couldn't get a consistent (or even acceptably different) look and feel on the handful of mail clients we investigated leading us to send our reports as attached PDFs, which are, in a lot of ways, preferable (they can easily be saved, for one).
As to your garbled message, it looks to me that your message isn't being correctly identified as HTML so the mail client is wrapping lines of text at 70 or so characters.
Your message is being translated somehow to "quoted printable" encoding. This is probably an issue with the mail headers you're creating.
Looks like it could be quoted-printable.
How do equals symbols in the HTML look, are they replaced by =3E?
Technically there's nothing wrong with this, but it would be nice to include an alternate plain text,
for those people who can't or don't want to read HTML mail (like me).
The email RFC enforces line length limits, specifically each line should be no longer than 78 characters, excluding CRLF. The equal symbols at the end of each line is just a line delimiter, which will be correctly parsed by any email reader that supports HTML, as long as the necessary headers are in place (Content-Text: text/html). More details on HTML in email conventions can be found here.