I have seen a few companies recently that are releasing "live" email content. This basically means that each time you open the email the content changes. I have looked into this and it appears that not only the image, but the text of these emails is also changing. . .
The only possibility that I have thought of to do this is with an iframe or changing images with the same url.
Does anyone have an idea of how this is being accomplished ? \
It would be easiest to find out if you just looked into the source code of one of those live emails.
Otherwise the most likely solution are <iframe>s. The support in mail clients is not encompassing however: http://www.campaignmonitor.com/blog/post/3219/do-iframes-work-in-email/
So I would assume this is mostly used for small areas, and/or with an <iframe ..><p>alternative content</p></iframe> area. That's the most likely approach to follow in lieu of scripting support.
The exchanging <img> variant is more widely supported, but harder to implement. You would need to take a screenshot of your website, and link it remotely in the mail. You can mitigate the non-clickability with an <area> but would have to ensure that your website screenshot doesn't change the layout then - because you can only ever adapt the remote image, not the sent html emails.
It's quite possible that both approaches might be combined. But it's quite some effort to provide an iframe and a static img screenshot as alternative. Only one thing is for sure, embedded Flash content can be ruled out for your "live" emails. http://www.campaignmonitor.com/blog/post/1974/the-truth-about-1/
Related
What would be the recommended way to securely view emails in a browser (in PHP)?
Emails are highly insecure content and desktop email software obviously implements only a very limited subset of HTML and no javascript at all to prevent attacks. But if I'd take an email HTML source and display it in a browser, javascript code and other stuff would be executed.
I thought a solution would be to send a header like this along with the email source:
header("Content-Security-Policy: sandbox");
But this would prevent me from fetching inline images from the server as I still would need a PHP session id to be transmitted to understand that the user is allowed to fetch this content.
As there are many web email clients out there I wonder if there is a best practice model.
(FYI: I try to implement my own web email tool fitting to specific needs of a larger software suite)
You can address the issue of images by not requiring authentication and then making the URLs hard to guess (ex: <img src="/resources/SomeReallyLongHardToGuessRandomString">).
More broadly though, securely displaying user generated HTML is hard. Like really hard. This is a case where you should use a library. Keep in mind that you might have a user with a browser that is too old for the Content-Security-Policy header. This browser would happily run any scripts on the page. HTML Purifier is my personal choice, but there are others. Also, keep in mind that this is a dependency you will want to update often as people are constantly discovering new bugs.
As an additional line of defense, many sites use a seperate domain for user generated content. For example Google uses googleusercontent.com. That way if something does slip by, they haven't compromised the whole application. Note that this would still be bad, as an attacker might be able to read user content they shouldn't be able to (emails in this case).
I finally decided to modify the HTML source of the email (in my php script) to serve the inline images as base64 encoded data inside the HTML source. Therefore no additional loading of images is needed:
<img src="data:image/gif;base64,R0lGODlhDgE3APf/ALJUMt3W0aMyFPTixGRHOXNXSvnu3b1sSu7SpPLduurTxapEIvbly/bq4+bAffTo31Q1J/369dGafaAtDO3o5ePd2c6Tdfz6+a9...">
This will solve the current problem of displaying emails, because then I can stay my
header("Content-Security-Policy: sandbox");
because it is one major way to prevent attacks to be successful. Additionally, for enhanced security, I plan to look again into roundcubemail and see if I find out how they handle this problem and also use HTMLpurifier to further strip the email source from possible threats.
Is it possible to include a separate html page in a php email?
Example, create a separate page that has all the content on it I want to email it and then include it in a php mail() on another page as the message?
Thanks
If you meant sending HTML email, yes. You can do that. You just need to add additional headers in the fourth parameter of mail() and pull the information from the HTML file you have using file_get_contents(). Please check this:
http://css-tricks.com/sending-nice-html-email-with-php/
Yes, it's possible exactly how rationalboss explained. Personally I use PEAR for html emails. It's a pain to get started with if you're not familiar to PEAR, but life has improved once I got it going.
Careful though, html/css does not have the same support in email clients that it does in browsers. You can create a beautiful page and find out that most people receive it with huge glitches due to certain CSS rules being ignored.
Best practice last I heard is to keep it simple and use inline styles for everything. Avoid floats and positioning. In fact, I believe it is actually still safer to use tables when dealing with email layouts if you need things to sit next to each other.
And then test in as many email clients as you can. Then cry and try to fix things.
I hear good things about Email on Acid for testing. It's a pay service but they offer a limited test for 3 clients as well.
If you're just doing a relatively simple email then it shouldn't be too bad. But if you're trying to make something that really looks great I recommend doing some googling on styling html specifically for emails.
for one of my customers I've been developing a mailsystem for his clients. His clients have been collecting e-mailaddresses in their stores and want to start using these for mailings once in a while.
I'm aware of all possible things that can go wrong, but as far as I can see we've got it pretty much covered the best way we can. We're using SMTP (Authenticated) to send the e-mails to the customers, e-mails are signed serverside, we're splitting up the mails with a max of 25 per 5 minutes, sending headers to optout location, etc. I can imaging this is just the tip of the iceberg concerning all things I have to take care off.. but I warned my customer that he might be better of using an existing app like MailChimp but he insisted on doing it ourselfs.
After the development of our beta version was done, we've ran some tests and all things went pretty well in fact. Haven't had any spamfolder problems, all mails are good to read in the different clients, and so on.
However, one thing is being a little hard right now.. the editor! We're creating templates for our clients (1 template, 6 styles). Our clients can load these into their editor and edit the text inside. As far as we (and the client) can see, everything goes pretty good, however - the editor does not create e-mail friendly HTML code (I should have known...)
I've searched the net for some articles/how-to's but there's really less to find about this.
Currently we're using CKEditor (Editor) and KCFinder (Image Plugin). As far as I know, CKEditor is the best free WYSIWYG available... but is it any good for e-mail editing?
I noticed some companies use a custom editor (MailChimp) others used TinyMCE (Enormail.eu).
Anyone has a good recommendation? Or is CKeditor the best option, but do I need to modify some of the settings to get the best possible html code for mailings?
Thanks in advance!
I have done a little research about it, because I'm interested in using CKEditor for E-Mail-based editing too.
Generally, CKEditor is the best WYSIWYG web editor, but you have to use some techniques that are not used usually in HTML pages.
Since your'e using templates (I guess CKEdtior's config.templates) most of your optimization will be in your templates, and not no configuration of CKEditor.
These are the main goals:
Don't use the <style> tag - instead, use inline styles (the style attribute). Some webmail readers does not read this tag.
Do not use config.fullPage = true; since some readers does not read the <body> tag.
Instead of using <body>, <div>, and other tags used for layout, use tables. Yes, this technique is old, but by doing this you can make sure that (almost) all readers will render the page correctly. Instead of applying styles to the <body> tag, use these style to the main <table> tag.
Don't use absolute positioning. Tables can also take part in the solution.
For all images - Insert the alt attribute, and for all width and height optimizations, don't use CSS-based width and height. I mean - Instead of <img style="width: 100px;" /> use <img width="100px" />.
In addition, one of the important things, is to customize and optimize output formatting. I personally change at least breakAfterOpen : true inside writer.setRules('p').
CKEditor is the most popular WYSIWYG web-based HTML editor, and I guess there is no other web-based editor for Email.
One more thing that I can think of, is that after your client is finished writing his message, there will be an option for him to preview the message in some popular mail clients. There are many Email testing and preview tools out there, but unfortunately I didn't find anything free.
I really hope that it helped someone!
I have worked for three years on a webmail. I could try tinyMCE, CKEditor or Redactor. None provides a perfect solution. You still encounter problems and you should always add functionalities. Some are too heavy, too slow, lack of features.
The one I found most effective is that of Gmail, but unfortunately, the code is not available.
The best solution is to create your WYSIWYG an even currently.
UPDATE
Try Squire made by FastMail.
I have never understood why some people say making custom css for each browser is a bad thing. To keep my page size down and download times fast it makes perfect sense to me to make a custom css for the major browsers (especially IE in its many different forms), and a general catch all css for everything else.
If you want to send out a bloated, huge, Swiss army knife of the css world, for all situations then go right ahead I'm not going to stop you.
Fast detection of the browser is important when doing this. Loading a JavaScript file to detect the browser seems slow. So I would prefer to use php to detect the browser, and send out the specified css. Or at least a general browser specific css then use the JavaScript to load a more detailed version of the css.
But I've read article after article about why this is a bad thing. The main reason behind each of these articles is because the user agent can be faked. Or there using Firefox but the server thinks they're using IE7 so it sends out the wrong css file.
As a developer/designer of web apps why is this my problem? If you want to use Firefox, but tell my server your using safari or IE*, and get a crappy looking page, why is it my problem?
And don't throw that whole if the user can't see your site right they'll never come back, or some kind of similar argument at me. a normal user isn't going to be doing this. its only going to be the people who know how to do this, and will know whats wrong when my site looks crappy.
This is similar to looking at my site on a old Apple II (I have no clue how), and yelling at me because everything looks green.
So is there a good reason, not a personal preference, why I shouldn't use php to detect the browser and send out customized css files?
I do this mostly for the different versions of IE. It just seems like for some sites, adding the if IE6 and if IE7 parts just double or triple the size of the css file.
Typically when a user intentionally fakes the user agent string, it is because something is not viewable in the user's browser that should be. For example, some sites may restrict users to IE or Firefox, but the user is using Iceweasel on Debian. Iceweasel is just a Firefox renamed for trademarked reasons (there are a few other changes also), so there is no reason that the site should not work.
Realize that this happens because of (bad) browser detection, not despite it. I would say you don't need to be terribly concerned about this issue. Further, if you can just make your site reasonably cross-browser compatible, it won't matter at all. If you really want to use browser-specific CSS, and you don't want to do so all in one CSS file, don't let a fake user agent stop you.
As long as the only thing you're doing is changing style sheets, there is no valid reason as far as I can tell. If you're attempting to deliver custom security measures by browser, then you'll have issues.
Not sure about php but in Rails it is normal and dead simple practice to provide css files and different layouts based on the user agent particularly when considering that your site is just as likely to be accessed by any of the myriad of available mobile devices, never mind writing for the most popular (Currently Firefox) browsers and even writing custom MIME types if need be is also dead simple.
IMO not doing so is pure laziness on the coders part but then not all sites are developed by professional teams of developers with styling gurus at hand. Also in languages other than Rails it might not be so simple. Sorry, I haven't a clue about PHP so this may not be an appropriate reply
In my opinion, starting with normalize.css, and having a base style sheet to start, overriding the base styles as needed usually works along with making sure you set appropriate fallbacks. If you really need it a few media queries, and feature detection can go a long way.
One reason you shouldn't base things off of the browser is because major search engines like Google and Yahoo prohibit displaying different content for different browsers. GoogleBot can detect different CSS and HTML and you may get bad search positioning. Additionally, if you use any advertising services you may be in breach of their contract by displaying varying content.
I am looking for creative heuristics to detect if an HTML email was not just opened, but also likely read.
Currently, we embed an img tag linking to a PHP script, which marks anonymously in the database that the email was opened. (We can assume here that the users we're interested in told Outlook it was OK to display the images.)
This method is okay, but it's hard to tell what it means - if they clicked the email just to get it marked as read, if they keyed through it while skipping through other mails, or if they genuinely read and enjoyed the email.
My latest try was to implement a delay of 10 seconds on the image download before making the database call marking the mail as read, however it seems that Outlook finishes the request in the background, even if they skip out of the email. Does anyone have any creative recommendations that may work better?
It's kind of unethical in my opinion to do this without your user's knowing. That's why so many email clients go to measures to protect against this.
I know this might not really help you, but if your user genuinely read and enjoyed the email couldn't you just add an HTML anchor in the email that they can click on to go to your website and you can add a tracking code to that to figure out who it was / which email address clicked on the link at the bottom of your email. Something along those lines just seems like a better method to me. Maybe that's just me though.
Hmm, tough one without the use of javascript, and as we know, most email clients have their security too high to use javascript.
Not putting much thought into it, could you use PHP's shutdown function, and have the image "loop" load....basically meaning that the image will never completely load because we are stopping it on the server side with a loop. Will Outlook still try and download the image after a timeout - will it timeout?
It seems like you are dealing with two different issues...trying to harness Outlook and trying to do something that most people don't want.
This is why there are offers and links like "click here for 10% off coupon" or "read more".
From a marketing standpoint this would be a true test if people are interested in your emails....but I guess that wasn't your question ;)