I am designing an html email newsletter. As you may know, this is a headache. We're currently going round and round with a few different email-client specific quirks like a game of whack-a-mole. You get something working in one client and it breaks another.
I know that on desktop browsers, is it possible – tho not advisable, particularly scalable, nor completely reliable – to do device detection server-side. What I am wondering is, is there any way to do server-side email client detection for html email newsletters?
Related
I have a problem. We've designed some beautiful, responsive email templates that work across mobile/tablet using media queries but contain MSO conditionals to work on Outlook. Turns out, the client now claims they can only send through an exchange-based mailing list. Ouch.
Problem:
If I send from Mac OSX's Mail, it retains the media queries and works (they are then stripped in Outlook when opened by receiver, but that's inevitable)
If I send from Outlook, it strips media queries completely and sends without them
From my thinking, the only solutions are:
Distribute through a different email client that supports both viewport media queries such as Mac Mail and allows connection to Exchange (know any? Thunderbird?)
Somehow obtain the mailing list and distribute through MailChimp or similar
Appreciate any advice anyone may have.
Depends on how good you care in code and whether you'll need clients to access your system. You can go with user friendly, feature packed options like Mailchimp or Campaign Monitor.
Much cheaper but less featured (relies heavily on you integrating through their api) is Sendgrid
If you want to stick to free, PHPList might be a good option.
I would like to know if and how it is possible to create a clickable email-link for websites, that are "encrypted" in a way emailspiders can't collect them and it is still possible for living users to click it to open in email-clients or even copy it.
I saw some links that were done in javascript but I on't know how they did this and how "safe" they are.
thank you in advance for any reply
Most approaches to this are splitting the address across multiple elements and inserting extra formatting; then for JS-enabled browsers, they use JavaScript to turn it back into an e-mail address.
The poster example for this is SpamSpan, which even has several "levels" of obfuscation - each level progressively less and less resembles an e-mail in the source code, yet it still manages to piece it back together by JS. Although some spambots today are supposedly capable of executing JavaScript, te vast majority doesn't - and the e-mails are still human-readable with JS off. An advantage of JS-assisted de/obfuscation is that it doesn't rely on external servers, you just need to (simply) integrate the JS library.
Another approach is taken by reCAPTCHA Mailhide - the e-mail is revealed only after solving a CAPTCHA (same type as for normal reCAPTCHA). This is less convenient for the user, but practically safe against robots. A disadvantage of this is that it depends on reCAPTCHA's servers (in essence, on Google) - some people are dead-set against any external dependencies.
This would be a very simple and effective way:
Scramble email addresses
All it does is convert it into ASCII, and all you need to do is insert it where your email address would go!
Although there are more (crazily) secure ways you can choose, this would be the simply option. You can also try this solution, it uses JavaScript to protect your email.
Hope this helps!
I'm nearing the completion of migrating our existing website to a CMS and I've just finished creating all the various contact forms. The CMS I'm using has CAPTCHA built into it's form builder, which is great, but the only method available is the "decipher-the-noisy-image" method.
This approach works well, but it limits access for people who might have reading or sight disabilities. I've worked around this by having a "help" page which allows those with disabilities to contact us by telephone and I'm considering having a single-field form which says "Send us your email address and we'll contact you". Accessibility is of particular importance to me as a web developer, but from an organisational perspective; so is reducing the amount of form spam we receive.
So what I'd like to know is, has anyone in the community had any experience with other CAPTCHA methods and how have you managed to make them accessible to people with disabilities?
As a blind person I find that recaptcha is one of the better CAPTCHA services out there as far as an audio option. The issue with using sms as the only alternative is the fact that many visually impaired users don't have cell phones that allow them to read text messages.
A good captcha, like reCAPTCHA, usually includes an audio CAPTCHA. Also I have seen a site that will
send a SMS message and you enter the code in the sms (Google-gmail will do this).
I am very interested in this because I am implementing a CAPTCHA in jQuery right now.
Many sites, including this one I believe, have an option to play noisy audio with embedded spoken numbers, as an audio equivalent to the traditional CAPTCHA image.
I find the result pretty spooky, actually. Reminds me of numbers stations.
As Michael said, audio with each character of the CAPTCHA text spoken for better or worse is a common option provided. If your CMS is PHP-based or if PHP is available on the hosting infrastructure you are using anyway, here's an open source CAPTCHA application with an audio download option:
http://www.phpcaptcha.org/
I've implemented a production site with phpcaptcha, and it works as advertised.
Do all modern email clients (online and desktop apps) support MHTML email content in which images and other resources are embedded in the email?
In addition is this the standard that should be used to get a consistent HTML email message out or is it better to send HTML emails with linked resources.
Note: I am aware of the 7 reasons why HTML e-mail is EVIL but it is essential in this case. Also I have seen the article on css support in HTML emails and know these pitfalls.
Pretty well all of them. MIME multipart is pretty durn common at this point.
Yes, just keep in mind that many clients do not load the images by default to avoid giving away "alive" account details to spammers.
Don't expect JavaScript to work (some users have it and it works), but Outlook/Outlook Express have had a bad history with JavaScript and IIRC have completely blocked it by default in recent versions.
Yes, I realize this question was asked and answered, but I have specific questions about this that I feel were not clear on that thread and I'd prefer not to get lost in the shuffle on another thread as well.
Previous threads said that rendering the email address to an image the way Facebook does is overkill and unprofessional user experience for business/professional websites. And it seems that the general consensus is to use a JavaScript document.write solution using html entities or some other method that breaks up and/or makes the string unreadable by a simple bot. The application I'm building doesn't even need the "mailto:" functionality, I just need to display the email address. Also, this is a business web application, so it needs to look/act as professional as possible. Here are my questions:
If I go the document.write route and pass the html entity version of each character, are there no web crawlers sophisticated enough to execute the javascript and pull the rendered text anyway? Or is this considered best practice and completely (or almost completely) spammer proof?
What's so unprofessional about the image solution? If Facebook is one of the highest trafficked applications in the world and not at all run by amateurs, why is their method completely dismissed in the other thread about this subject?
If your answer (as in the other thread) is to not bother myself with this issue and let the users' spam filters do all the work, please explain why you feel this way. We are displaying our users' email addresses that they have given us, and I feel responsible to protect them as much as I can. If you feel this is unnecessary, please explain why.
Thanks.
It is not spammer proof. If someone looks at the code for your site and determines the pattern that you are using for your email addresses, then specific code can be written to try and decipher that.
I don't know that I would say it is unprofessional, but it prevents copy-and-paste functionality, which is quite a big deal. With images, you simply don't get that functionality. What if you want to copy a relatively complex email address to your address book in Outlook? You have to resort to typing it out which is prone to error.
Moving the responsibility to the users spam filters is really a poor response. While I believe that users should be diligent in guarding against spam, that doesn't absolve the person publishing the address from responsibility.
To that end, trying to do this in an absolutely secure manner is nearly impossible. The only way to do that is to have a shared secret which the code uses to decipher the encoded email address. The problem with this is that because the javascript is interpreted on the client side, there isn't anything that you can keep a secret from scrapers.
Encoders for email addresses nowadays generally work because most email bot harvesters aren't going to concern themselves with coding specifically for every site. They are going to try and have a minimal algorithm which will get maximum results (the payoff isn't worth it otherwise). Because of this, simple encoders will defeat most bots. But if someone REALLY wants to get at the emails on your site, then they can and probably easily as well, since the code that writes the addresses is publically available.
Taking all this into consideration, it makes sense that Facebook went the image route. Because they can alter the image to make OCR all but impossible, they can virtually guarantee that email addresses won't be harvested. Given that they are probably one of the largest email address repositories in the world, it could be argued that they carry a heavier burden than any of us, and while inconvenient, are forced down that route to ensure security and privacy for their vast user base.
Quite a few reasons Javascript is a good solution for now (that may change as the landscape evolves).
Javascript obfuscation is a better mouse trap for now
You just need to outrun the others. As long as there are low hanging fruit, spammers will go for those. So unless everyone starts moving to javascript, you're okay for now at least
most spammers use http based scripts which GET and parse using regex. using a javascript engine to parse is certainly possible but will slow things down
Regarding the facebook solution, I don't consider it unprofessional but I can clearly see why purists may disagree.
It breaks accessibility standards (cannot be parsed by browsers, voice readers or be clicked.
It breaks semantic construct (it's an image, not a mailto link anymore)
It breaks the presentational layer. If you increase browser default font size or use high contrast custom CSS, it won't apply to the email.
Here is a nice blog post comparing a few methods, with benchmarks.
http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/