I've seen many websites (especially websites developed/designed by NIC - India) which write emails in following form -
mail[at]example[dot]com
But I personally like writing it this way (preferably in mailto: anchor tag) -
mail#example.com
Keeping in mind the reputation of NIC,
Does first form of writing has any advantages? Or it's just some old age tradition?
Which one is better considering accessibility of websites (ie screen readers etc)?
[Instead of subjective preferences, I would like to compare them on merits for sake of accessibility of websites]
Short Answer
mail[at]example[dot]com is an antiquated and inaccessible way of displaying email addresses in an attempt to stop web scrapers.
It makes things harder to use for everybody and nowadays is very unlikely to offer any protection so use a normal email address if you must (or better yet a contact form if spam bothers you, although I could write a whole book on how it is difficult to stop spam.)
Long Answer
Does first form of writing has any advantages? Or it's just some old age tradition?
The first version was designed originally purely to stop web scrapers from gathering email addresses.
However nowadays most web scrapers are pretty smart and will know to look for that format so I think the benefits are minimal.
You might get 10% less spam with it but that is a pure guess / conjecture.
Which one is better considering accessibility of websites (ie screen readers etc)?
Lets look at how they are read out:
mail[at]example[dot]com
This will be read as "mail left bracket at right bracket example left bracket dot right bracket com".
As you can imagine this is not ideal!
Also bear in mind that an American speech synthesizer may say "period" instead of "dot" so you make it less accessible there as it is not a familiar way to say it (minor point but important)
Along the same lines if you ever try to internationalise the site it will be a lot harder as you would have to change [at] and [dot] for a language specific name for those items.
Finally people with cognitive disorders may not associate mail[at]example[dot]com with an email address and get confused as to how to contact the company.
mail#example.com
This will be read like a normal email address "mail at example dot com". All the problems I cited above disappear.
The best option
Obviously the best option is to not have email addresses and use a contact form, but that is from a spam protection perspective.
If you don't mind the extra spam lists you will end up on then use the second option. You should also make this a link that opens the users mail client e.g. mail#example.com
When using a mailto link there isn't much you can do to protect yourself from spam as web scrapers are just looking for an email pattern and will almost certainly be looking for mailto: as an indicator of an email address, hence why we might as well show the proper email address.
Making it a link also has the added benefit that when a screen reader user navigates a page by links they will find the email address (one of the ways screen reader users orientate themselves in a page is to iterate through all links).
Displaying as an actual email address also means that everybody can copy and paste the email address to their email client if for some reason you don't make it a link or the link doesn't open their email client (they may not have one for example).
I would imagine asking someone on a mobile phone to try and copy the link with [at] in it and format it correctly would result in mistakes, frustration etc. resulting in lower conversion rates.
But I really really want to show mail[at]example[dot]com and I don't care about making it hard for people
Then you could make the email address appear like this but get read correctly in a screen reader.
We can do this using visually hidden text or using aria-label. I have included both as an example below.
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<h2>Using Visually Hidden Text (more robust)</h2>
<p>Will be read like a normal email address "mail#example.com" is what a screen reader sees</p>
<p>mail<span aria-hidden="true">[at]</span><span class="visually-hidden">#</span>example<span aria-hidden="true">[dot]</span><span class="visually-hidden">.</span>com</p>
<h2>Using aria-label (a lot easier)</h2>
<p>We use aria-label to override the contents of the paragraph for screen readers, yet again "mail#example.com" is what a screen reader sees</p>
<p aria-label="mail#example.com">mail[at]example[dot]com</p>
From accessibility point of view both are similar. Try by yourself using Voice Over or some other screen reader and both will be read the same.
I guess the idea was to write email addresses as the first form to make spammers more difficult to harvest email addresses from web pages.
Related
Lots of people seem to recommend hidden preheader text. For those who don't know, preheader text is a way to control the e-mail content preview, like this:
An example of hiding it would be:
<div style="display:none;font-size:1px;color:#333333;line-height:1px;max-height:0px;max-width:0px;opacity:0;overflow:hidden;">
Wishing you a safe and merry holiday season!
</div>
I'm wondering if hiding this preheader text from humans reading the e-mail might increase spam score or impact deliverability? In the world of web crawlers, hiding content from users but not machines (so-called cloaking) is a big no-no, and it can really hurt you.
Does anyone know if spam checkers might employ similar logic? I've seen some conjecture online, but not much in the way of solid references. Any anecdotes, quotes, or links on this topic would be helpful.
Short answer: yes, it can.
More detailed answer: add hidden text is exactly what spammers do, to bypass spam filters. Every spam filter can detect this hidden-zero-height-zero-width text and - depends on its configuration - will take that into account for the spam score calculation. It's certainly not a single spam marker, but with all the rest of your email, that might brings you over the threshold.
SpamAssassin can be configured to detect that.
I understand, that this is great for marketing purposes, but to get my stuff delivered, I would rather avoid it.
Carsten is right, hiding text in your email and playing with the email client behaviour to get it displayed will increase the spaminess of your email.
I have been working as a developer on antispam filter for several years, hiding text is a very common spammer technique. It is used to outline several words (or even letters) of a block of random text to display the spammer's message, making it harder for antispams filters to identify a common pattern.
Same way, hiding text between a subject header and the first mime part (another kind of preheader) is a common spammer technique.
Alone, these criterias may not be enough to get your message blocked. But added to other spam criterias (ex : if you message has already been identified as a mailing list), that may give you some bad surprises.
This is a recurring question on the website, but after spending 20 minutes browsing through old questions I was unable to find a modern day solution.
I've previously employed this JS-based method to protect addresses. Before the JS-method I was using image and flash-based solutions. Below is my old way.
Animated example codepen: http://codepen.io/anon/pen/kIjKe/
HTML:
<span class="reverse eml">moc.niamod#tset</span><br>
CSS:
.reverse {
unicode-bidi: bidi-override;
direction: rtl;
}
.eml {
display: inline;
}
JS:
function reverseEmails() {
if (jQuery(".eml.reverse").length > 0) {
jQuery(".eml.reverse").each(function() {
var that = jQuery(this);
var email = that.text().split("").reverse().join("");
that.removeClass("reverse");
that.html("<a href='mailto:" + email + "'>" + email + "</a>");
});
}
}
None of these methods seem to work nowadays, since Node.js based scrapers are able to generate an image of the page they are scraping, then reading any human-readable data from said image - you can guess the rest.
Is there any method that works nowadays, in which users are still able to easily read / click / copy paste e-mail adresses, but JS-enabled bots could not?
This is personally my favorite method, which I have found to work so far, it's not bullet proof, in theory a bot that can parse CSS3 and will preform a text search can still find it or a spambot that triggered events in order to harvest email addresses would have to feed the page into basically a headless browser, somehow determine what might be JS-obfuscated email content these scenarios are enormous amount of work for possibly no benefit and no spammer would ever consider doing it, the fact is I have had no spam to date and it works great for humans, both to read or click on:
<style>
.email:after{ content:'#mydomain.com'; }
</style>
Contact me at:<div class="email">myemail</div>
<script>
$('.email').click(function(){
window.location.href='mailto:'+$(this).html()+'#mydomain.com';
});
</script>
The thing is that the email is not a link so bots never trigger the click event as they don't even know it will do anything.
Put the email address on a separate page which is only reachable by solving a CAPTCHA.
Granted, then the security is only as good as the security of the CAPTCHA.
Using your own obfuscations may be a serious alternative if you only have a limited number of addresses you want to protect. Some ideas I have used in the past;
Crossword puzzle. Make it really easy, with cues like famous song titles with one word missing (easy to google and no debate about possible second interpretations). You can fill in many letters to make it even easier.
Audio recording with background noise. I didn't want to use my own voice so I used a speech synthesizer, with a German accent (-: AT&T web demo IIRC) and mixed in a couple of seconds of music in the background (Frank Zappa's Peaches en regalia worked very well for me, but tastes differ).
Hand drawn image. I like to draw letter outlines but I doubt they are regular enough to pass any OCR.
The real beef here is not the stellar brilliance of these solutions, but the different approaches which I hope can inspire you to think in new directions. In the end, you will always be safer if you come up with your own unique solution; anything resembling a "new de facto standard" will be the lowest-hanging fruit that the scrapers will spend time trying to pluck.
Incidentally, I tried to think about usability for people with disabilities, so I actually deployed the audio version as a fallback for people who have issues with interacting with the other two, which are based on visual layout.
By the by, very few people want to send me email these days anyway (or maybe they do, but end up being rejected as spam?) which is frankly a relief. Those who do typically use the whois registration info for my domain name (which uses an anonymized address provided by the whois registrar) or are good guessers.
I suspect your intuition is correct, if an email address is displayed on a page then a bot can scrape it.
Your best bet is to involve the server-side in some way.
For example, if you just want visitors to be able to reach you, then you can add a "contact us" form like this one: https://store.theonion.com/t-contact.aspx
If you want visitors to be able to reach eachother, then you might need to build an anonymization system like Craigslist uses.
My current honey pot on my registration form is an entry for phone number which is placed off screen using position: fixed;.
It tricked a standard breed form filler, but doesn't work as well as I though. Also, the spambots immediately responded to changes in the form, meaning that this is automatic, what can I do.
Note: I hate captchs since the make they users solve my problems which is never good.
Build a really smart honeypot
That may seem obvious, but here are a few tricks(Details later):
Think Like a spam bot
Assume that they are able to know what is on screen or behind other elements
have multiple traps.
Time Trap
Honey pot
1. Think like a spam bot:
Start going through your page like a spam bot, You can even write your own which can waist time but is quite fun :).
Most spam bots will crawl through the markup looking for a <form> element. Then they will look at your inputs and fill them in appropriately, which is the catch: how do they know what to fill in. They will prbably look at the Id, class, placeholder, and label. which brings us to our first method
Method #1:
Mis label inputs in your form code. Bascily your username input should have the Id of #Form_Email boom! spam bot fills out form incorrectly. Also hide and mislabel your inputs labels, use divs instead.*
Method #2 starts here
You've probably noticed that if you simply ignore hidden stuff, based on location what is in front of it and even the good old display: none;,visibility: hidden;,opacity: 0; or type='hidden'. This gives us a powerful weapon. I discovered this by accident while testing a time trap. I used a basic form filler to fill the form. On my site(I'm not talking about GiantCowFilms.com), the register form is in a dialog that opens when a user clicks a register button. By default it is hidden. This gave me an idea for
Method #2
Default: form is hidden. Basically, your form is hidden on page load, but is uncovered by some mouse based action(I don't think bots have mouses). If you wan't your form to be visible on page load, add a I identical decoy one which is above the real one in the markup.If the bot fills in and submits it, block its Ip for a few minuets.** For really users, simply when the mouse hovers over the decoy form, switch them around.
2. Assume that they know what your page looks like
Assuming that hiding honeypot with CSS is perfect is a grave mistake. Their are a lot of super smart screen readers like JAWS that could be repurposed for spaming. That is why you have multiple lines of defense.
3. Have multiple traps
Time Traps:
Going back to thinking like a bot, would you wan't to wait on a site instead of attacking others?
Method #3:Create a time trap.
The best way is to print a time in a hidden input when the page loads. when you submit the form, it tells you how long it took. Fill the form as fast as you can. That should be the minimum amount of time to fill your for.Note: encrypt your time stamp so bots cannot change it. If you wan't to get really fancy, measure the WPM of the bot typing. This is done on stack exchange( try copy and pasting then submitting and question/answer). Also if the rate of typing is very consistent, that is a red flag.
Honeypots (Method #4):
Use all of the above at once for best results. Make sure to trick dumb bots as well as smart bots (don't assume the bot is always trying hard.).
Now, in order to spam us, bots will have to have cursors, render the page, wait, type at a variable realist speed. If they make a bot like that, Then I guess it'll be Captcha time :(.
*People using screen readers will trigger or be confused by these defenses, and depending on your country you could get into trouble for discriminating against blind to semi-blind people. Therefor, when a user triggers the bot test, take them to a non loaded form with a disability friendly captcha like reCaptcha.
**People often share Ips and you can chase away valid users.
P.S. Use simple honey pots like you already have. Some bots are just too dumb to get tricked by what we have here.
For years, I've used my own 'form spammer trap' that uses a variety of techniques to block spambots. The most effective is to obscure fields (especially the form's 'action') for a short time period. Since the bot scrapes your form for the fields, and the 'action' page, and uses that info to "CURL" your form data, putting false info in those areas will fool just about all spambots.
After a timeout (JS-based), the obscured values are replaced with their actual values. By the time that happens, the spambot has moved onto another target, and using the bogus values will fail.
I've developed this whole process into a free solution available at my "Form Spammer Trap" site https://www.FormSpammerTrap.com . That site has been around for years, and the contact form there has yet to be successfully 'spam-botted'. (You bots are welcome to try.)
To implement in your site, you add one 'include' and three functions. And you can customize the form with some advanced techniques.
For those that are interested in how a spambot works, and why common 'tricks' such as hidden fields don't work, see here: https://www.securitydawg.com/how-bots-spam-contact-forms/ .
My 'FormSpammerTrap' solution is free (PHP-based), and is available via the Contact form (just check the box to get the free code). No obligations; I don't even save your email address.
But it is quite effective. IMHO.
Added 21 Jun 2020
The "FormSpammerTrap" solution is still around, and has had significant updates over the years. The latest version allows a lot more (and easier) customization of the form, although the basic use only requires one customization entry. The documentation is greatly improved.
And I am working on version 9, which will add even more customization. It should be released in a couple of weeks.
The https://www.FormSpammerTrap.com site has full details of the latest version, how it work, and a link to a blog entry I wrote about how form spammers work (and how they can be blocked).
And it is still free - just fill out the contact form on the site and check the box and get it immediately, with full documentation and samples. It's fully guaranteed or your money back! (well, it is free...)
(And thanks for the upvote. )
Added July 2022
The program is now up to version 15, with version 16 in the works. There are tons of new features, but the process still works - it blocks all bot attempts on a contact form. Take a look at the changelog on the web site.
And, it's still free.
I am creating a new template design for 1shoppingcart, but although the email is formatted correctly for most emails, on Gmail the format is slightly off. There is a grey horizontal line at the top and bottom, and in the email there are white squares that don't fit inside the lines of the email.
I read that I have to use tabling for Gmail emails. Does anyone know what the issue might be and/or any people who I could pay to fix this?
Thank you,
Conrad
There are also a "soft cap" on the number of characters in a single line of HTML that can be submitted in email (it is around 700 characters). If a single line/element of markup exceeds that soft cap, it won't stop the email from being sent, but may cause some formatting breaks or other changes.
Remember that you don't need super flashy emails to make an impact, many people's mail clients (local, cloud, and webmail alike) are configured to reject graphics and other more advanced design techniques for security purposes. Keep your communications short and to the point and try to make it all fit as best as possible.
Also, with 1shoppingcart, you can set up a TEXT/HTML (MIME) email so in the event a customer could not read the email in HTML they could still view the text version.
Read this article design-guidelines about designing html emails. Maybe it will help you.
Quote from article:
Because clients like Gmail and Outlook
2007 have poor support for float,
margin and padding, you’ll need to use
tables as the framework of your email.
Aside from the visual splendor of HTML emails - links are the only thing keeping me from sending plain text emails. They are much simpler for users at times and reduce bandwidth by over 50%. However, forcing my users to copy/paste or (* shiver *) type the URL from the plain text email is not acceptable.
However, it seems like many services such as gmail and hotmail are converting URLs into HTML links. If that's true, then for some lighter emails I could finally switch to plain text (in certain cases) without bothering anyone.
Anyone know what percentage (or what systems or clients) convert text URLs into clickable links?
Some users access via the web (Hotmail/Yahoo/Gmail) while others use clients (Outlook/Thunderbird).
All email progams I know make links clickable, web-based and normal ones.
You should consider putting the links at the end of the mail, and use "[number]" to refer to them:
You should really visit PEAR[1] and friends, PHP[2]!
[1] http://pear.php.net/
[2] http://www.php.net/
That frees you from problems with longer URLs within the text, and it keeps the text readable.
You must not forget one simple fact and that is every mail client make this configurable. So I for one have the option of reading / sending html emails but I don't do that. So it's totally irrelevant how many mail clients support this, the relevant question is how many users have this enabled.