How to determine the "content" of an email? - email

I've been curious about something for a bit, that has to do with Gmail (and other clients) when displaying the content of an email.
How do they determine what is the "content" and what is the "footer" or replies/signature/etc.? What I mean is that when looking at an email that is from someone personally, Gmail will almost always, perfectly, hide the signature by default but still allow you to expand the email to see it. How do they know what to hide and what not to hide?
My Google-fu isn't working for me here, I think I'm using the wrong words maybe? I thought maybe there was something about the HTML content of the email but that clearly wouldn't be reliable, plus it works just as well with text/plain emails.
What's the "trick"?

Related

Links inside email are displayed as double plain text

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

Outlook Signature delete images

For my work, we stumbled upon a little problem. We have made a few mailboxes, and when a user send a mail to this mailbox, it will make a ticket in our ticketing system.
That works fine! But our signature contains images, and our ticketing system takes these images as attachment. This is not what we want.
I tried making a transport rule to delete the signature, when we send it to one of these addresses, and looked it up on google. I saw on more sites that it was impossible to delete a signature with a transport rule.
I tried making a rule in outlook too, but i can't find anything.
Does somebody have the solution for this? I hope so! :)
Thanks in advance for thinking with me!
Look at the HTML body and find all the images. Delete attachments with the matching file name of the content-id property that matches the src attribute of the img tag.

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

Prevent hyperlinks in HTML emails (namely Outlook)

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

What are some ways to protect emails on websites from spambots? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 months ago.
Improve this question
I'm creating a public internet facing website which contains the email address of their salespeople.
What kind of programming options do I have to generate the "mailto" and display the email from that address but limit the spambots from picking up the address?
Recaptcha has an excellent capture based email protection. You can see it implemented at the bottom of any page in my website using the Site Feedback link.
I know that Facebook does it by displaying an image instead of text. Sure, they could use OCR on the image, but why bother for just one email address?
If you really didn't want spam bots to get an email address, the best way is to never show it to anyone. Show a link to "Contact this person" which brings up a form. On the server side, send the contents of that form to the recipient, with a reply-to of the sender's email address. Include a little blurb at the bottom of their message that "if this email is spam, please 'click here' to block this user", which will then block the IP of the sender. I've used this method on a number of occasions and have never had a single complaint.
You can obfuscate it but IMHO whatever you do, one day spammers will get your email address. The future is in spam filters, not trying to keep email addresses secret.
What I have done in the past is use javascript to build the mailto: link. This is nice for the users because they can just click on the link and I don't know of any spambots that take the time to execute javascript yet.
I think I got the idea from Jakob Nielsen's useit.com website.
In the page header I have this piece of javascript:
<script name="mailto" language="JavaScript">
//<![CDATA[
function load()
{
c1 = "bcl"
c2 = "brian"
c3 = "lane"
c4 = "com"
// Fill in the addresses
document.getElementById("contact1").innerHTML = "" + c1 + "#" + c2 + c3 + "." + c4 + "";
}
//]]>
</script>
Tell it to load it when the page loads:
<body onload="load()">
And then in the body of the page I put a link to a spamtrap:
<span id="contact1">spam#brianlane.com</span>
If this is not a static HTML page, but a ASP.NET, JSP, Coldfusion, or PHP page then you could have a drop down box with a list of all your sales people, a text box for comments, and a "Contact Us" (ie, Submit button). When the button is clicked, it will call a server-side code which creates the email and sends it to your local mail server for delivery. The outside world will never know the email address of your sales people, nor the email format (ie, firstname.lastname#yourcompany.com) of your company.
Have a look at PrivateDaddy - I think it does exactly what you're looking for: fully automatic, unobtrusive email cloaking that even works with browsers where JavaScript support is disabled. You can get it here (free of course)
I have a solution, well, more of a theory.
Problem is, the bots parse the page. they can get the text. even if it's being put
into the page in some sophisticated way through Javascript.
So, just you CSS3 pseudo element! it won't be a link, but your email will be visible, and will never be an actual text. something like this:
.email::after{ content:'myemail#gmail.com'; }
Again, it's a theory, I've no idea how far these evil people can go to get it, but I think this be pretty safe.
Update (JULY 19')
I now in the opinion this isn't a problem since email servers have become good at filtering spam and there's no reason to make any elaborate tricks to "protect" email text on webpages.
You can use something like email obfuscation
This is a difficult problem. If you post an e-mail such that it can be parsed by a web browser so that it's clickable, then it can be parsed by a spambot. If it's not clickable (e.g. if it's an image), it's more difficult for users. On one side is perfect, seamless experience for users and on the other side is perfect spam-blocking. A simple CSS or javascript to take in an email address as separate tokens is usually better than nothing, though.
You could only show a part of the e-mail address "us...#mail.com" as a link that redirects to a captcha, then display the full e-mail address like Google Groups does.
We used to do classic ASP string cat for email addresses, the grand idea being that spambots read source, but don't parse server-side code. I have NO idea if that actually works.
Would something that I wrote work for you?
http://kevin-le.appspot.com/viewSource/sourceShare/asmRevealer.js
...and you could see the demo here:
http://kevin-le.appspot.com/extra/contact
It works with mailto, so it's convenient for users, but spambots won't be able to pick up which is your requirements. It'll be obvious once you spend 1 minute looking at the demo.
I got the same problem too and i came up with a quick but effective method to help my website out.
Basically bots just read the content of the web page but in 99.999% they do not trigger events, it would require a great amount of dedication and work, things hacker don't usually do in favor of bigger numbers and quicker effects.
So i came up with this function:
function emptyMail() {
let mail = document.querySelector('#your_mail');
let mailValue = mail.href;
mail.href = "";
mail.addEventListener('mouseover', function() {
mail.href= mailValue;
})
}
This worked for me i hope it can help you too.
I see the mailto: protocol almost dead anyway... It is convenient, but too easy to parse and gather.
Plus it has its downsides: if you are on a Web cafe, it won't work because it will call whatever default e-mail client it has (if it has any!) and it is not set up on your account. Same if you use exclusively online e-mail managers...
A possible workaround is to decorate e-mails, relying on users to type or correct them: foo (at) example.com or foo-NOSPAM#REMOVE-THIS-example.com are common schemes (hoping spammers doesn't try to decipher these common schemes!), graphical e-mail addresses are another way.
Or, as pointed out, if you can, the best option is to have a contact form, with some reasonable form of protection against robots, that would be usable from everywhere. Although people might be defiant on forms asking for e-mails (for response!), so a disclaimer might be useful too... :-)