e.g. Google Webmaster Console does it by asking website owners to upload a file with specific name. Other services use the same approach.
Is there any reason why not verify ownership by simply asking people to confirm by clicking the email that was sent to the email under that particular domain? (provided that website does not give out its users email addresses like gmail etc)
Because it is the most direct and 100% bulletproof way to find out if the guy has the control over the site in question.
Email address "under" the domain can belong to the admin while the site is actually managed by the developer.
Also, many use anonymous registration, in which case email will be sent to the registrar address (though it will usually forward to your real address or at least notify you).
I have a GMail account doesn't mean I own the gmail.com domain. Like 'Developer Art' said, uploading a file shows that you have access to web-hosting portion of the domain.
How would they know that you are the person at that domain responsible for the website unless you modify it in some way? I have a company e-mail address - that doesn't mean I'm responsible for the company website.
I can prove that I "own" Yahoo, Hotmail, Gmail, and many others with your proposed verification technique. What's so hard about uploading a file to a server for someone doing web work?
I think the intent is, "If you own the site, please place this verification file in your site's root directory." Once the verification system sees the file there, ownership is verified. At the very least, it confirms the ability to post to a site's root folder. Not having this expectation of your users might open you up to folks doing malicious activities as someone else's site because you didn't properly verify ownership. In legal circles, we call that, "due diligence."
E-mail... you know, I keep receiving messages from banks I don't have accounts with, the British Lottery and even more from a guy in Nigeria. They look real. Now that I think about it, maybe I should forward all of their e-mails to each other. The lottery guys and the Nigerian guy can put all their money into the fake bank accounts. Spam problem solved!
Related
I want to build user registration into a website. Could some one advise if it's necessary to setup an email confirmation system? I feel this could greatly annoy the user.
I find this very annoying, If you have to do it you should also consider giving users an option to authenticate themselves again social sites like twitter or facebook.
There are a handful of reasons why it’s important to verify an email address:
Security: being able to send your users reset instructions, or any important updates about the site, etc.
Spam Prevention: By forcing a user to confirm
their email before performing any substantial actions on the website, will help combat spam and your website from being filled with fake users.
Avoiding Shutdowns from Email Delivery Systems: Systems like Amazon Simple Email Service will flag your website as not trustworthy after a certain amount of emails are sent through their system that end in bounces. Personally have had this happen because I wasn’t monitoring them in my own system architecture.
Payments: if your website requires payments of any sort, you’ll want a method to contact the user.
Newsletters: if you want to let your users know of some action related to your company or website, you’ll want to accurately know how many people you’re emailing… or even be able to email them and not just a trashcan full of fake emails.
I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.
We have a password reset web application. The application sends out an confirmation code to an alternative e-mail. My manager believes it is not a good idea to include a link to the page were you have to enter the code.
I see his argument. However, the helpdesk has been overwhelmed with users who are confused about the process. I'm assuming this is because many our users browse using only one tab/window and navigate out of our web application to check their e-mail for the confirmation code.
My question: How should we approach this issue? I would like to alleviate helpdesk and, in turn, make the process pain free for our users. Any suggestions?
Clarification
He believes that we are doing the user a disservice by training them to click links from a sender that cannot be verified (in this case, it's an automatic message with a "no-reply" address). This, would in turn, make users more susceptible to phishing attempts which we've had a lot of issues with in our organization.
I think sending links is the standard way of doing it. If a customer is really worried about the integrity of this email account, he better gets that sorted out first.
Essentially you don't gain extra security by not sending the link, but you gain a lot of comfort. Just do it like everyone else - put it in there (time limited).
The only thing on the top of mind would be the option to have a unique identifier in the e-mail's subject an have the customers reply to that mail.
Then an automated script checks 'password-forgotten#mycompany.de' for emails with the subject 'Re: Forgot your password? [UNIQUEID]'. The script would then mail them their new password.
Since most users won't modify the subject when hitting "Reply To" and won't do a "Compose new mail" and enter the recipient address manually, chances are big, incoming mails to "password-forgotten" will have that UNIQUEID in the subject.
Plus helpdesk would only have help those that actually modify the email's "Subject". ;-)
There are security considerations, though. Maybe your manager might argue, that anyone might send a forged "Forgor your password" mail and set the "Reply-To" header to the attacker's address. The processing script has to intercept these attempts of forgery...
I see no reason why the link shouldn't be included, especially if the code is something like a hash because the chances of somebody cracking that are slim to none.
You could however, add an extra protection to the page where the code is being inserted and limit the number of tries to something like 3. For even more protection, send the email address to that page as well, and allow 3 tries per email address instead of 3 tries / IP, which can be easily bypassed.
One of my clients ended up getting sucked into the "Domain Registry of America" scam letters that they send out and has now effectively lost the domain to them. My clients name is still the registrant, admin and technical contact but all the other details - address, phone, email - are for the DRoA. I expect we will not be able to get the domain back because of this. Anyone have any possible solutions other then waiting for the domain to expire?
Thanks
I think your client might possibly want to pursue this with his lawyer. It's possible that DRoA acted fraudelently. No doubt that DRoA has their scam all figured out, so it's unlikely that your client will get his domain back without ponying up some cash, but a nice legal nasty-gram might shake them up a bit.
In my website (under development), the members can send messages to each other which are sent directly to their email, now I'm worried that some members can send spam to other members (I have a spam filter but it doesn't give 100% protection as you know), I'm worried that my domain might get blacklisted on Yahoo, Gmail, Hotmail or AOL which will cause any messages sent from my domain to end up in the spam folder, this is why I want to add the domain of my website to their whitelists (if they exist).
P.S. I don't want to use private messages that members check on the site and I have my reason for this.
Thanks
Your email might not be considered "bulk" because it sounds like it's one->one as opposed to one->many, but these bulk mail help resources might still be helpful:
Yahoo! Mail Postmaster Help
GMail Bulk Sender Guidelines
Windows Live Hotmail Postmaster Services
AOL Postmaster Website
As Bevan mentioned, your task will be an ongoing one to keep your site clean on various services.
Not sure if you're already considering this, but you can send the email "on behalf of" the requesting user (i.e., set the from and reply-to fields to the user who is sending the message).
While there may be whitelists used by those sites, I suspect that they only contribute to whatever scoring system is in use - being on the list won't be sufficient in itself.
The overall controlling factor will be the "reputation" of your site - you need to work to ensure that reputation stays sound.
Unfortunately for your workload, I think this will be an ongoing task, not a one-off.