This question is more theoretical.
Is it save to be passing email address in query string like:
www.something.com/?email=person#domain.com
I am using this in one project, but i would like to know what are the downsides. Cause some big services are avoiding this, for example Gravatar wants you to convert email address into MD5 hash and then pass it in query.
Thanks for explanation
The main one is privacy.
Take Gravatar for instance. The traditional usecase is rendering an avatar for each comment. If you were to put the real email address in the query string, then you would be publishing the email addresses of everyone who commented (perfect for harvesting by spam bots or for harassing people who make comments that you disagree with).
Related
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.
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 send 3 different links to people on a daily basis. I know the name of the person I am sending the link to. How do I attach that persons information to the link to know they clicked on the link?
I sent close to 50 emails to different people. I just want to be notified that someone I sent the link to click on it.
You need to use a database for this. The link could contain a random hash that can be looked up in the "emails" table. This table could keep records for timestamps, specifically when the emial was sent out, and when the user clicked the link.
#QUESTION:
Most hosting providers give you the option to hook up a database. If you have trouble finding this, use google or their support. As far as how to "use" a database, you will need to learn this in you own time. But like anything else the basics are widely available through google, which in your case, is all you need to finish your project.
You can add an encrypted or obfuscated field to your URLs identifying the email address.
Common methods:
base64 encoded email address XOR-ed with known key
md5 hash of email address truncated to first N characters
And so on.
The first method allows you to reverse the process (i.e. getting back the email address from the visit log), the second is one-way only.
For example, using the second method with email dude#gmail.com (truncated to 12 characters):
http://domain.com/click.php?v=ec3ab9422d7a
Or, as already said, you can simply use a database and store a key-value pair (email, hash) with, for each email, a random string generated on-the-fly by your massmailer.
I want to develop a system with which users interact by sending in email. Very much like most email discussion groups or like posterous.
What checks should I apply to incoming email to make sure it comes from the address it claims to be?
There is no method of authenticating email in a reliable, universally available and easy to use fashion.
The best way of handling this is probably by giving your users a unique, hard to guess email address to send their emails to (something like 459f71b01809458adfe17a7d838dcb19#postbymail.yourdomain.com). You authenticate them based on the assumption that they're the only ones who know that address. When you do this, you also need to add a way for users to invalidate the address and generate a new one (in case it was compromised). And don't forget to make it easy for them to get the address in places where they can't easily copy & paste it, like on a mobile phone (easiest done by adding a button that sends them an email with the generated address as sender).
i have an application that has to return emails to a user with his email client, but in some cases I have to pass around 1000 emails.
I'm using mailto on href, something like this:
mailto:info#useremail.com?bcc=email1#test.com,email2#other.net,anotherone#dfsf...
Why am I returning to his email client instead using PHP mail() function?
Because the user sender email depends on which computer he is using, and he needs to archive thoose emails.
The problem:
Some browsers, if the email list is bigger than X, it won't send to his preferred email client.
You could output the full BCC list and ask the user to copy-paste it in. But maybe you should just rethink your entire strategy if you want to pass thousands of e-mail addresses to a user.
That's because the length of a GET request (and such a link is a GET request) has a maximum. On some browsers it might only be 2083 characters. So any email address behind that limit will not be send to the client email program. And thousand of email adresses will break the limit.
For anything other than a simple mailto:address with no parameters, mailto: URLs are massively unreliable and should be avoided. URL-length issues are only the beginning.
on some cases i have to pass around 1000 emails...
Even if a mailer could cope with getting the URL, a user's residential ISP is unlikely even to allow them to send that.
Give up. Send the mails yourself from PHP. Send a copy to the user for the archival purposes.
Passing a user thousands of email addresses is very unusual.
Generally, a more typical application would use PHP mail() on the server side, and then allow browsing the archives of whatever notifications have been sent out. The mail stays on and is sent from the web server, but allows the user to see what's gone out in the past.
On the minus side, that's a good bit more code, but probably the only way to fix the problem you're having; mailto: wasn't meant for large volume.