I have mailto links with which I allow users to manually put the recipient's address by leaving the mailto link empty, like so:
Share
But when tested in tenon.io, it complains about the empty email address:
Do we have a workaround for this?
Karl Groves here, Founder of Tenon.
Tenon is purposefully opinionated. The goal of the product is to assist website owners in ensuring an accessible user experience. Weighing strict technical conformance vs. user experience is a constant dance. Ultimately the end user may need to choose to ignore some of our guidance.
It is true that the mailto: protocol does not require an email address. And, in the case of #qtgye's link, it is a valid use. If I was #qtgye I'd ignore Tenon's result.
However, we do consider this to be a useful test. In response to this thread, I posted a Twitter poll: https://twitter.com/karlgroves/status/869208982250024960
98% of respondents do expect an email address in a mailto: link. The reason why this is an accessibility issue is that mailto: links will open the user's email client. Users who cannot see the entire screen may assume that the email address is already filled-in on their mail client.
That being said, we do have to take into consideration the fact that the email address is not technically required. Each test in Tenon has a certainty score which, as the name implies, indicates how certain we are that it is a real issue. We will be lowering the certainty score on this test. We are tracking that adjustment as Issue TEN-2573 in our issue tracking system.
Thank you for bringing this up #qtgye
The mailto protocol does not require an addr-spec definition. So your link is valid, and this is a false negative.
Related
Is there any reason a site login needs a username/password? If an email address or cell number is supplied a text or email could be sent back at which point you would click on the link. Would this be enough to be considered authenticated by the site. Much like a password reset email/text, except you would be logedin instead.
Maybe this is not the correct forum to post this.
But, usually an username gives more sense of "ownership" / sense of belonging to an account.
Also for security reasons! I'd rather not give my personal email to everyone or in some places.
And if they already ask my email, I would imply my username is the information other users have access to, and not necessarily my email.
e.g. a Forum / Payments / etc...
I'd like to know if the following is actually possible:
A mailto link that does not contain an email address, but somehow auto populates the TO: field with the email of the original sender.
For example:
"a href="mailto:ORIGINALSENDER?subject=UNSUBSCRIBE&body=I would like to unsubscribe from future emails">Click here to send an unsubscribe email /a"
Is this possible without having to specify an email address in the link itself? Is there a class or function i can call to autopopulate the To: field?
The reason i ask is we send out curated email templates to individual customers and they are sent via a specific system. This system does not have an unsubscribe function, unfortunately. I am not able to use or suggest a system that does as i am but a lowly cog in the corporate machine.
In a word, no, not dynamically in an email that I'm aware of. Are you sending from the same email address each time? Can you set up an additional email address to handle unsubscribes and just have that hardcoded? (i.e. unsubscribe#yourdomain.com and have that monitored)
If you're using different email addresses, then consider replacing 'click here to unsubscribe' with something to the effect of 'to unsubscribe, reply to this email with unsubscribe in the subject line'
Lastly, making a recommendation and giving a good argument for using a system that better suits your requirements is a first step towards being more than a lowly cog in the corporate machine :)
I've recently found a web site where the email address is included within hidden tags in a html form. Is this a bad practice and why other than the stealing of mail addresses?
It's a bad practice.
A malicious user can use a tool like Firebug to change the hidden field's content.
He can then use your form to spam or send anonymous emails, as an example.
It is an alternative in using session to store the email value for a certain purpose.
Assumably, a field called "to" contains the email address of the organization being contacted. Since this doesn't vary by customer, it shouldn't be part of the form; it should be part of the form's target script.
Even if the "to" email is somewhat variable (say a limited list of webmaster, technical service, sales, complaints dept, etc.), the form should not contain the target email. It should contain a dropdown send-to list where the option values are integers that are used by the script to determine which email address is appropriate. Aside from security concerns, an option list like the one described is easily generated from an array. So changes to your email list are easy to make.
Keeping the email address off the contact form helps prevent misappropriation of your form for spamming. And it also keeps your email address(es) private from webscrapers.
It's just a way of keeping track of the email address that must be required somewhere. Since they can't figure out by themselves your email address, I suppose that you entered it in the system before, so I wouldn't call that stealing.
As for practices, I'm not a big fan of hidden fields since they are so easy to change, but it can do the job if needed. Of course you need to have all sort of data validation on the backend treat hidden fields as if they were user inputs.
Where what email address?
The email address the form will get submitted to? It isn't very clean, but there is nothing terrible about it. (If the server side form handler doesn't check the email address against a white list then it is an invitation to spam relay, and that is terrible).
The email address the user entered on the previous page? No problems, this is just maintaining state, and it can't be stolen - only the user who entered it in the first place will get to see it. (This half of the answer removed in response to comments)
Does it make any sense to include a captcha when registration already requires email confirmation? any added benefit or just a waste of effort?
Neither will prevent current bots from getting into your system if that is your reason for doing these. Usually email confirmation is done to validate that the user gave a correct email address if you have need to contact them (or spam them). I don't see the value in adding a captcha to that.
I have tried sending and HTML formatted email using ACYmailing for Joomla AND Mailchimp. It works for yahoo, msn, aim, my work domain but not for gmail.
I can send plain emails from my server to gmail but the HTML formatted newsletter doesn't work.
Someone suggested it may be my HTML code ~~~> Pastebin
I couldn't find a problem with it.
Some ideas:
Maybe GMail recognizes it as spam. Try some different content
Did you set the headers of the email correctly?
Did you specify a correct sender / sender name?
Are you receiving a rejection or failed email response? If it is being rejected you should get an email explaining why which will be sent (although you will need to specify a correct from / reply-to email address to receive this).
The first thing I would check is if the IP you are sending from has been blacklisted by any spam services - most deliverability issues I have experienced have been due to this. You can check a fairly extensive list of spam blacklists (together with some additional email validation services) at MX Toolbox
If everything appears fine there it may be due to Gmail's fairly strict antispam criteria. To be accepted, an email should contain in the headers a valid email address for Return-Path. If this is not valid then there must be a Reply-To header with a valid email address.
Another important weapon in Googles antispam arsenal is SPF record checking - essentially a way of validating that an IP address is authorised to send email for a particular domain. This is worth checking however as far as I am aware a missing SPF record will only cause the mail to go into spam rather than not be delivered.
Gmail has three tabs now, especially if you're part of their partner network. I encountered the same issue until I noticed the three tabs. They are "Primary", "Social", and "Promotions". All of my MailChimp email wound up under the Promotions tab. Check there for your emails from MailChimp and possibly other e-blast emails. I don't have the solution yet on how to get MailChimp emails to go directly to the Primary area of the inbox.
Just in case you're actually sending the HTML you reference in your question, note that it's invalid - you haven't wrapped it in the necessary <html> and <body> tags.
I realize it's likely you just forgot to include those tags in the pastebin reference, but just in case. Note that the w3c validator found several (minor) errors in the referenced fragment.