Yahoo is removing the href attribute from the <a> elements from emails that we send for registration approval or password reset.
We are using Sendgrid web api to send mails using nodemailer-sendgrid-transport module.
After googling possible answers, I am certain that:
We are using complete urls (starting with https:// at the start of the url).
We have added target="_blank" attribute to our <a> elements.
Our emails don't go in to spam. So it's not related with disabling links in spam issue.
However these didn't solve our problem.
Is there any way to prevent yahoo from disabling links by removing href attribute?
Issue is not occurring when on other mail providers such as gmail etc.
Given that the email is NOT in the SPAM folder, then adding rel="nofollow" to your <a> tags and also being sure to use the full url (including the http or https) should fix the issue.
<a rel="nofollow" href="https://www.myurl.com">Some Text</a>
Related
In our web shop we email customers after each purchase. Up until now all emails displayed properly, but now, in some cases all links inside the email is displayed as doubled plain text. This is happening only to some customers, and I can not find anything about that issue and how to solve it.
Correct Display:
Incorrect Display:
NOTE 1:
I created HTML for that email. The link is wrapped with <a> tag, but when we inspect the incorrectly displayed email, the <a> is removed and only the text is present in the DOM.
NOTE 2:
This is only happening to some customers. We checked and they don't have any ad blocked enabled. Also, this is not browser related issue since they also tried to open email on different browsers.
This happens with Outlook.com and Outlook 365 environments. If the link does not have a http:// or https:// (or other) protocol, it will do this.
Therefore, ensure all your links use a protocol, i.e. ..., and NOT ...
Just in case anyone else winds up here ... we had a similar issue
Our HTML bulk-email (sent programmatically via Exchange) showed formatted correctly in SENT ITEMS, but arrived (when viewed in Outlook) somewhat broken. It was fine if we emailed to e.g. GMail / Hotmail, so probably only a problem with Outlook rendering.
The Outlook presentation was PLAIN TEXT and not Rich / HTML. Noticeable because "View Source" was greyed out. (The content, as sent, definitely had HTML / HEEAD / BODY etc. tags, and it validated OK at W3C - Outlook removed all such HTML tags - seems strange that Outlook decided to display in plain text and then remove all the, correctly coded, HTML tags)
Some, but NOT all, yyy tags displayed wrongly - in particular the tag https://www.example.com/ was what we, eventually, found had caused the email to render (in Outlook) as plain text - all HTML tags stripped and some LINKs rendered wrongly. That HTTPS link did render correctly, but others in the same email which were coded as www.link.com/MyPath rendered as
www.link.com/MyPath<https://www.link.com/MyPath>
same with mailto: links
Removing the HTTPS:// from within the <a href...>HTTPS://xxx</a> tag fixed the problem - took us a while to find though!
So basically it seems that the HREF property should include https:// and the value within the <a> tag should NOT
I am sending emails to users which includes a one-time authentication link. I am trying to develop a feature through which if a user forwards the email to some other user, the links should get disabled.
One way is to hide the link by using a style tag which is covered here:
<style type="text/css">
blockquote .original-only, .WordSection1 .original-only {
display: none !important;
}
</style>
<p class="original-only">
Content to be hidden Unsubscribe.
</p>
Is there a better/standard way to achieve the same? I would prefer to keep the link visible but clicking on the link will take the user to my web where I can check URL params to validate if the email is original or forwarded.
I don't think it would work, but for a different reason - Office 365 can "probe" the link first to see if it points to anything untoward. Your server would register a hit, but it won't be coming from a user.
A foolproof way forward is essentially not possible, although you may be able to do it with some success on some platforms. (There isn't even a way to target all email clients individually on a straight send--let alone on a forward!)
What happens when you forward an email is that the email will be re-rendered, often without the accompanying embedded CSS that you are relying on (it depends on the email client).
So the reference to the class would be lost, and your link would now show after a forward:
<p class="original-only">
Content to be hidden Unsubscribe.
</p>
Furthermore, I see what you are trying to do there, in predicting that a forward would add a blockquote or a style like WordSection - but not all behave predictably, or if they do, you can't target them. For example, Gmail will add a class that begins with something like "_m" (from memory), but although CSS can target that with an [attribute^="value"] selector, most email clients will ignore this 'advanced' CSS.
In fact, you may have more luck reversing this:
<style type="text/css">
blockquote .original-only, .WordSection1 .original-only {
display: block !important;
}
</style>
<p class="original-only" style="display:none">
Content to be hidden Unsubscribe.
</p>
I haven't tested it, but if you sent that to, say, Gmail (noting some Gmails are different from others, e.g. IMAP/POP accounts), which DOES support embedded CSS, you would see the unsubscribe link. But forwarding might just remove the embedded CSS and so the display:none would kick in and hide the link.
However, if you sent it Outlook desktop, which does NOT support embedded CSS (anything in <style>...</style>), it would hide the unsubscribe link by default, as well as keep it hidden on a forward (probably).
Results are likely to be all over the place.
We are sending html emails through amazon ses. It appears that gmail is altering the href tag and making it unusable. It almost looks like it's putting tracking information there instead of the original link. Below is what we are sending to ses and what we see in the client's email. It is happening for all href tags in the email, but not every email going to gmail.
Sending to ses:
<a ses:no-track href="http://www.Google.com">www.Google.com</a>
Client email:
<a href="http://esfsecev-ty3014" rel="noreferrer" target="_blank" data-saferedirecturl="https://www.google.com/url?q=http://esfsecev-ty3014&source=gmail&ust=1541799752348000&usg=AFQjCNHRj6rzLaQFMfQQPtoDE_Q9RTTFQQ">
www.GoSurvey.com</a>
Thanks in advance!
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
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.