Prevent hyperlinks in HTML emails (namely Outlook) - email

We've got some HTML emails that get sent out that show email addresses our service has blocked. When viewing the email in Outlook (and presumably in other clients as well) these plain-text email addresses get turned into clickable links that would compose a new message to this address when clicked.
Is there a way to prevent this from happening? Perhaps a meta tag with a flag that would prevent Outlook from converting these into clickable links?

Most email clients strip out META tags, Javascript, and other types of code not necessary for email. Outlook is going to do what it wants with your email, so what you may want to do is wrap the addresses with your own anchor tag and use a blank HREF. Then, style the link to look like the rest of your text.

I think a better answer is to formulate anything that you think a mail client might try to generate a link for in a way that breaks up the string a bit like this: https://stackoverflow.com/a/7625887/470749

Related

IDEA: Do you think this would stop emails from being scraped?

I put a span class in the middle of the email, like so:
example<span class='scrape'>DELETE-THIS</span>#website.com
I set the scrape class to position:fixed and right:200%. The email address appears normally on the page. Then I added some Javascript that deletes the span on mousedown, since bots can't click.
What do people think? Would this stop an email from being scraped?
Most bots target a links with a regular expression looking for an # symbol and sufficiently complex ones are capable of parsing the content of a document as well as its html. While this might hinder the ability of a bot to parse it via html it does not hinder the plain text methods.
A better defense is to store the email address as a Data-Attribute and then use an event to transform it from the Data-Attribute into a MailTo: link or however you wish to use it. This will cause the page to be loaded asynchronously which will prevent most batch style bots.
This is called "email address munging". It would be cleaner to use display:none though.
It works on some bots but not all.

HTML Email Not Generating Links (A tags) in Outlook

In checking an email that I am coding (a reply-type email that my server will send), I notice that the a tag hyperlinks in my code are not working in Outlook. They work elsewhere, but not Outlook.
I know very little about Microsoft products, but I can tell you that the place I'm seeing this is in the online outlook.com you view in a web browser.
The simplest link, such as this...
Click here
...is coming through like this in the rendered email:
[http:www.yahoo.com]Click here
AND, it is not a link. It's just text. It appears as though the program is disabling the links (possibly because it finds the email suspicious of phishing, even though I added the domain to my trusted emails)???
Anyone know what is happening or how I can work around this?
I don't see anything wrong with the code you've posted, but I do know that Outlook.com will do this to links when it doesn't recognize them as valid links to an external site. Look for hidden characters, "smart" quotes instead of plain quotes, etc. in the link.
You should put the target on the link.
Like this:
Click here

Show/Hide content in a Gmail email body

Our organization is completely on Gmail (Google Apps), and we are trying to figure out a way to show/hide content in the body of the email and have the recipient decide whether to show the content or collapse it to hide it.
The reason why we need to do this is because we send out generic emails in various languages, so we want the recipient to simply click on their language and have the email show the text in that language.
Things we want to avoid:
Sending multiple emails out in different language (and have to manage email recipients languages and multiple emails).
Display the content for all the languages one after another in the body of the email and have the user scroll down to their language.
One way I thought of doing this is by using Javascript to show/hide a div in the email that would hold the content for each language. For example, I would have an "English" hyperlink, a "Spanish" hyperlink, a "Chinese" hyperlink, etc and on click, the JS would show the div associated to the language that was clicked.
However, I was not able to get Javascript to run in Gmail when I sent a HTML email from an email client (Thunderbird).
The solution I'm looking for should ideally only require Gmail as some of the users do not have access to browse any other site outside of Gmail from their Chrome browser.
The simple solution would just be an HTML (no javascript) email with a "table of contents" at the top showing the various languages. Clicking a language in the table of contents would jump to that language's anchor in the HTML (and thus, the correct language message body).
The hard way to do this would be to write a Gmail contextual gadget:
https://developers.google.com/google-apps/gmail/contextual_gadgets
Options that don't work:
JavaScript doesn't work in Gmail
Pseudo-selectors aren't supported, so you can't do anything like :active td { height:100px }
display:none and visibility:invisible aren't supported
Ideas that might work
Point the image to your server, and get the HTTP headers. With a combination of HTTP_ACCEPT_LANGUAGE and the IP address, you should be able to serve up the appropriate image.
In Gmail labs, there is an option to add apps by XML. You could write an app that lets you do more advanced stuff, and tell your users to install that.
Personally, I wouldn't worry about just displaying the content one after the other. Put an index of the languages at the top of the email, with anchor links to the relevant language.

How can I send an HTML email from a browser client?

I want to send an email in HTML to a user from browser client i.e send mail from Gmail, Yahoo, etc.
I paste the HTML I want to send in the text area, but the HTML is not getting rendered when I receive it.
HTML emails need a content-type: text/html header otherwise they are assumed to be plain text. You do not mention what language you are using, but if you are using PHP, you can use PHP Mailer to make sending HTML emails a little easier.
<textarea> tag is for user input. Users can't insert any data in mails, so this tag won't be rendered. If you just showing the information, use tag <p> instead.
http://www.labnol.org/internet/send-html-email/19672/
Be careful with how you use this though, GMail could very well blacklist you if your recipient list is too long. I use it all the time for tests.

using form buttons for spamproof email-addresses

I have been looking at some methods for spamproof email methods here. I'd like to propose a more simple approach: Since I need a couple of different email addresses I considered just using a selectbox with JS or serverside redirect, as per examples on here.
Because google doesn't spider forms (dixit Matt Cutts), and spam-harvester script don't either (I think????) this would make sense to do.
I would love to be able to do this without using a script. So why not use one form per email?
<form action="mailto:test#domain.tld" method="get">
<input type="submit" value="test#domain.tld"/>
</form>
It seems the button text can be copied but not pasted, so that's a disadvantage.
Is this approach any good? or any other recommendations?
A robot uses the text of the page to get the email. It does not care if that text is in a button or within the body so using a button will not help.
Outside of using javascript, the only solution I know of would be written text, an image or Flash.
Create an image with your email or write out the email like: "test at domain dot tld"
Flash could provide you with a more secure (but not 100%) way of allowing people to click on an email but would not work on iPhone browsers and those that do not have the plug-in.
Another way is to use a simple captcha to before displaying the email in the PHP code.
Email: (1+2 = ?) then test#domain.tld
Because:
The email address is still in the page, and thus easily harvestable
mailto: URIs as form actions often fail
The reason server side form handlers stop email addresses being harvested is because the email address is not exposed to the user.