I don't have a technical background, so I'm presuming there's a simple answer for this:
Why does Gravatar require you to create a hash of an email address before sending a request to their system? Is there a technical (or social) reason not to just use the email address?
It's to prevent exposing the email addresses to harvesting. If the raw email addresses were used in the avatar URL, it would be a simple task for spammers to harvest those email addresses for their nefarious purposes by scraping the HTML/DOM of any forum using Gravatar.
There are two reasons.
Reason 1:
When you make a call to gravatar, the url looks like this:
https://www.gravatar.com/avatar/37dj383ks?params=blah
This means, on, say, a blog or internet forum, as a guest or signed-in user reading comments where gravatar images are used, the html source code would look like this:
<img src='https://www.gravatar.com/avatar/37dj383ks?params=blah'>
If they weren't hashed, your website's public HTML source code would look like:
<img src='https://www.gravatar.com/avatar/ bob_smith#example.com ?params=blah'>
<img src='https://www.gravatar.com/avatar/ susan_suzanna#example.com ?params=blah'>
<img src='https://www.gravatar.com/avatar/ jason123#example.com ?params=blah'>
<img src='https://www.gravatar.com/avatar/ francisbakery#example.com ?params=blah'>
Any website that'd be using gravatar, would automatically be leaking publically every single one of their own users' email addresses.
Reason 2:
The second reason is, any website that'd be using gravatar, would automatically be leaking to gravatar their users' email addresses.
If I sign up at a website, say, Stack Overflow, and I give Stack Overflow my email address, I don't want Stack Overflow to send my personal email address to other companies like Gravatar.
But if I have already given Gravatar my email address and set up a profile picture, then the hash of my email is a shared hash that both Gravatar and Stack Overflow know.
Stack Overflow doesn't have to trust Gravatar. Gravatar doesn't have to trust Stack Overflow. But by simply providing the one-way hash of the email, neither has to actually hand out any of their users' sensitive information.
Related
I'm wondering if it's possible, through perhaps pixel tracking or another means, to know an email recipient's IP address to provide location-based dynamic content?
The most reliable way would likely be to embed a tiny image in the header that links to one of your servers. Then when the open the image you can get their ip address based on where it was accessed.
Pixel tracking is easy,
but you mentioned "dynamic content".
This means you need to make your email content change after the recipients open their email, which can only be achieved by javascript.
As far as I know, some email clients will block javascript execution, see here.
If you can use the first mail to record user's ip address, and store in database, you can use the information in the second mail.
Or you can provide a link in your email content, which leads the user to a dynamic webpage.
#Aviator provided a nice solution of generating dynamic image to solve the problem.
I yet read some posts on the argument, but I'd like to know if there are some "new" best practice to follow to avoid email clients (thunderbird, Outlook, gmail, ect) block remote images in a html email.
Of corse images in the email have alt description; but there is a way to be considered a secure host to which download images?
Thanks
The biggest thing that affects whether your image will load or not is user interaction. If the user has added you to their address book, responded to your email, sent replies back to you or clicked on links, the email client will add you to the white list and ensure that your emails will be delivered, rendered and isn't spam.
The best thing you can do is send engaging content and give the users a reason to interact with your email.
There are also services out there, like Return Path's Email Certification that will cost you quite a bit of money but ensure much better deliverability to their partner email providers.
I know this is likely to be answered "sorry buddy", but is there a way i can access my recently sent emails from another iOS app? I really don't need the contents of the emails just the addresses. Basically if you haven't stored the contact information in your address book, I still want to be able to pull those addresses.
For example in the email app, when you compose a new email, as you start typing in an email address it will try to autofill with recently sent/received email addresses. I'm trying to mimic this behavior.
Point me in the right direction if there is already a stack overflow question about this.
No, there is not API that will allow this.
Apps can't acces other apps data since they are sandboxed.
Given the quick answers I received confirming my suspicion that this can't be done, I'm thinking I will just provide a way people can set up email accounts the way the built-in mail app does it. By that I mean I will allow people to select from the major web-based mail providers like gmail, yahoo mail, .. then also allow them to create a mail account with their mail server (address, username, password, port, etc.)
It's kind of overkill since I just want their recently used email addresses, and will scare off people who don't want to give access to their personal mail, but if its all i can do then so be it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I just want to ask you why is email activation useful. I mean when you register on a website, many ask you to activate your account by email. Is this for preventing spam, or just for websites to be sure you entered a real email address, to send you emails in the future? If it is for spam, how is that preventing spam, cant bots access mail, or what?
EMail activation is primarily used to ensure that you're signing up with a "real" email address, and also one that you have access to (and therefore, presumably, are the legitimate "owner" of the email address).
This enables the website to be able to contact you at some later date since it now has a legitimate email address for you, the user. This can be used for password resets, or general communication etc.
EMail activation also effectively prevents you from signing up your friend/enemy even though you know their email address, unless you also have access to their email account, which is unlikely.
This is mostly used to stop one person from registering another person's email address with a site in order to generate spam from the site to the innocent victim. Most website's that employ such "email validation" will ignore sign-up requests unless they are "verified", usually by clicking a "secret" link or entering a "secret" code back on the website that is originally sent in the email message.
Many legitimate website users are sometimes distrustful of giving their "real" email address to websites for fear that they themselves will recieve spam from the website. Many times, this depends upon the user's trust of the website that they are visiting.
To this end, there are a number of services (such as Mailinator, SpamGourmet, and many others) that legitimate and non-legitimate users alike can employ to provide a "real" email address that is accessible by the user, yet also disposable and temporary to allow the user to ensure that they recieve no spam to their real email address.
This, to some degree, can defeat the effectiveness of an "email validation" system employed by a website, since the website now cannot guarantee that the user (identified by the email address) is "genuine" (i.e. it's not a "throwaway" email address). To this end, many website will prevent users from registering with an email address on a known "disposable" domain.
It verifies the supplied e-mail address and also prevents registering somebody else for an account or mail-list.
At least: If you forget your password, a password reset link can be sent to that email address.
There are many reasons
That way you can make sure password recovery can be done
You can be sure someone will not register someone else email to spam him
You will be protected from spambot
I think its for both , i.e to avoid spams and to make sure that you have entered a valid email address that you have access to
Well, I suppose the main reason is spam prevention and password retrieval, but if your users do something illegal, you might want to identify them.
It sure helps to ensure a valid email addresses but also helps to avoid bots that automatically register and then proceed to spam forums etc.
I'd say it's a mechanism to keep "one-stop users" away, as you have to enter a valid email adress which you have to be able to check to gain access to the website.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have my domain's email set up with Google Apps, and I am interested in sending automated emails (when users register, for example) with the From and/or Reply-To field being "no-reply#example.com". I have a few questions pertaining to how this is done:
Should I actually set up a user in Google Apps named "no-reply"?
If not setting up a "no-reply" user, should I log in with a real address (e.g.: "support#example.com") and send the email as being from "no-reply#example.com" instead? Or should I simply use the Reply-To email header?
If it's necessary to use the Reply-To header, is there a way to block the true From address (i.e.: the username I used to log into Google's SMTP server)?
Yes, you should setup a separate noreply address on your email server.
There are excellent reasons why you should set up a no-reply email address.
Why is it important to have a no-reply on bulk emails?
Many of the recipients of the email will try to hit 'reply' and they will have a multitude of reasons for doing so. Often, it is not sensible to have all of these going to a single representative at your company. Furthermore, many emails from bulk lists will be bounced back. You don't want to have to sift through these in order to find legitimate questions from your mail outs.
The best way to respond to questions rather than replying to bulk emails, is to have the recipients direct their questions to appropriate response emails either through their usual contact or via your company website.
What if recipients DO hit the reply button?
The email originator for the bulks should not just silently swallow the replies. Many companies do this and as a result, legitimate replies are ignored without any indication to your client or potential client and they, feeling neglected, go elsewhere for business.
The originating email account should be set up with an auto-responder explaining that the email was not processed and suggest alternative ways of contacting your company.
In gmail this can be done by setting up a Vacation responder with no last day. You can find the Vacation responder feature under the General tab of the account settings.
Avoid having extra accounts by setting up no-reply as a group that restricts users from outside your domain sending to it.
Unless you can think of a really good reason for it, I would suggest that you send your emails from support# rather than no-reply#.
The whole reason for a support# email address is to receive comments and feedback from your userbase, and if you're sending them emails why bother making it hard for them? If they can just reply to the email you'll receive way more feedback that way.
I suggest you set up a "Nickname" alias ( Manage Domain > Users > edit user > Add Nickname ). Then create a filter that sends any reply to that nickname straight to trash or spam.
Just set up a "no-reply" account. It won't hurt anything, people will still try to send stuff to it, and it will serve your purpose.
As for the latter two questions, it depends.
If you're sending these e-mails as a part of an automated script (i.e. forum registration) just use the "no-reply" accounts credentials. Log in periodically to make sure you aren't getting legit delivery errors (as opposed to the jokers that use fake e-mail addresses) or other odd behaviour.
If you're not sending these e-mails as a part of an automated script, it depends. If you also manage a support address (support#example.com, staff#example.com, etc.) you may want to send on behalf of, and use the reply-to. But this part is a little more subjective, and really depends on your setup.
I don't know if this will help or not, but IIRC, with gmail you can do something like
name+something_else_here#domain.com
Then, set up a filter so that emails with that "something_else_here" part go past the inbox to a label.
Does that help?
I think creating a user named no-reply is a bad approach. An alias or a restricted group is a much neater and functional solution IMHO. Also, google apps cost is based on user number.
A cool way to handle this would be using the vacation setting in GMail to send an automated response back on the no-reply email address. The vacation reminder would then remind users that this is an unmonitored email address.
I think the right thing to do is setup a filter that sorts your mailer-daemon messages into a special folder (Or trash if you so desire.) Or, like other comment have suggested, use a separate mail address.
noreply is good to indicate to people that this isn't an address you check, but it's not really the solution to dealing with bounce mail. In fact it's more likely your mail will end up in spam filters because your attempt at sender obfuscation will just look like spam to the receiving host.
You should create a noreply user. But use it as a spam mail (when registering unknown sites) and a mail for testing.