I was thinking about creating a service similar to posterous where users can post to a fixed address like post#domain.com and then authentication of the posts would be based on some combination of the from address and header signature. Posterous seems to be doing something clever so that they can detect if a message is being spoofed or sent from an unknown source.
Anyone know what they might be doing?
There are some basic heuristics you could use, to try to detect it.
The most basic thing would be to look at the originating host and headers of the previous emails and see if they match previous ones. If the poster's email domain uses SPF you can verify the IP address has permission to send on behalf of that domain. It's easy to spoof an email - it's harder to spoof an email and actually have it originate from a subnet that matches where your previous mail has come from. But that can be subverted, as well.
First off, the email you post to should be random and unrelated to any display name. This keeps random strangers on the net from knowing where to post in the first place.
You could also go far more sophisticated and implement some sorts of machine-learning-ish things (or even more straightforward heuristics) to pick up on style, but that would be much tougher to get right.
Or just be lame, and upon receipt of a post, fire back an email to the poster with a link to verify and/or a special token to send back as a subject (if they're posting from a phone, etc. with no browser).
Related
using email analysis we can find senders IP address through some tools only if they are from different domains like senders sends from yahoo mail to gmail user.
How to find senders IP if they are from same domain?
example:
from: abcd#gmail.com
to : wxyz#gmail.com
while in email analysis iam getting senders IP as google servers IP
What you can actually achive with any tools depends very much on whose IP address you want to find out:
If you want to get the address of the client, on which a user probabply typed the email and from which it was transferred to its provider's Mail User Agent (MUA), forget it. As long as you are not a government with the appropriate court decision or very good friends with the server operator, the latter one will not give you even slightly sensitive information about its clients, also not the IP address.
If you want the IP address of the MUA of the client's mail service provider, you have much better chances. Assuming that the from field is correct, then just check out which addresses this provider uses. Gmail has probably a lot of various server machines and I think you might not find the exakt IP of the server the sender's client connected to. If the from field is manipulated (junk mail), Gmail's Mail Transfer Agent (MTA) will probably reject the mail, so that it will never arrive in your inbox anyway.
The sender and the recipient may use different mail service providers, in that case your provider's admin could have a look into the server's log files to find out from which IP address the recipient's provider's MTA was connected. However, usually this is absolutely irrelevant, as long we are dealing with two respectable organizations. Also you explicitly mentioned that in this scenario, it is one and the same provider.
Finally, you can find out the address of your own MUA, but I think that has nothing to do with the author of the email.
So, in conclusion: technically you can't. The only really interesting information is the address of the client used by the author of the email. Google is a respectable enough company to never ever give this information to you, except if the sender's mail client explicitly wrote it into the mail header, which it probably never will.
If you want the IP address because of criminal activity or any kind of abuse by the sender, just contact Gmail. If that does not help, file a lawsuit. The latter one may actually take a long breath until you (may!) be successful, so be sure if your situation is really that bad.
However, if you have a lot of criminal energy you could use the more general metadata from the header to create a profile of the sender's client, like which client software of which version he*she uses and more. But I think this is going to be very, very much work until you get more relevant information (and it should be).
It would actually be very helpful to have a few more information on your scenario, e.g. what you need the address for, if you really mean the client's address or the mail provider's server address, how much work you are willing to invest and also which kind of mail service provider we are talking about. If you run your own mail server, you suddenly gain access to a lot of interesting information...
Feel free to clarify your needs, so maybe someone can help you better. Also, I hope I didn't hit you with too many words, I am new and excited about stackoverflow ;)
I have been trying to figure out how to programmatically check if a gmail account exists. Almost all searches lead to validation services like xverify or EmailOversight where you validate any email address on a cost per request basis.
What I am interested in is a way to do that directly, without a middleman. In other words, how do these validation services do it? Seems like there should be some sort of an API that google provides for those guys to ping to see if an email address is valid.
Please note that I am not interested in checking the syntax of an email address. So I am not looking for some kind of a regex solution.
Also, what I have tried is connecting to gmail.com MX record domains (e.g. alt3.gmail-smtp-in.l.google.com) and trying to extract the validity of an email address by running simple SMTP commands. Essentially what this article suggests: https://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/
But I cannot do that for any kind of volume. Gmail will start blocking your connection attempt after a certain number of connections. So that method is not scalable. That's why I feel like there has got to some other way.
*******ADDED*********
Here is why this question is different from How to check programmatically a email is existing or not
That post provides only one solution, and it's one I have already tried - using SMTP commands. Google will NOT allow to do that on any kind of scale. If I only had to validate a few emails, then that would be a sensible solution, but if I have 10,000, it is not.
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.
I am trying to create a newsletter for our business.
The last few days have been spent testing, and one of things I have noticed is that MSN seemingly randomly filters out some of my test messages.
This is super-frustrating.
I like the PEAR Mail MIME-package, and have been using that. I may send one email from one of our servers, resulting in the message getting through, and in the next minute, the same message sent from our other server ends up in the junk folder. Then if I add an attachment to the email, and the same message passes though the filter from the server that was previously blocked. I think. What the ####? Is this like throwing a dice, without me having any control over what is trash, and what isn't?
I have sent email from several servers, all of which are shared. But I am unsure this is the problem. The problem is that it is seemingly random how MSN filters email. Some emails get through, and some other don't for seemingly irrational reasons.
I am running out of ideas, but I am not giving up. Therefore I am writing to you for HARDCORE technical info on how MSN filters spam.
First of all, this is probably better suited for ServerFault. The problem is more infrastructure related than application related.
This is a common problem and isn't completely solvable especially if you are using shared mail servers. But there are things you can do to increase the likelihood that your mail will be accepted by mail services.
Run your own mail server, do not use a shared server. This way you will have better control over the mail server's reputation. Mail server reputation is important, as others using the server can cause its reputation to drop, which makes your mail to be less likely to be accepted. The important thing is to have your own dedicated IP number.
Make sure you have reverse DNS set up for your mail server. Not having reverse DNS properly configured is a great way to have your mail rejected.
Use SPF, SenderId, DomainKeys, and DKIM. I believe MSN uses SenderId. These provide you with a way to tell the other mail server that the sending mail server is an approved server for sending mail from your domain name. If these pass, then the mail is much less likely to be spam. Here is an article on these things:
http://www.digitalsanctuary.com/tech-blog/debian/setting-up-spf-senderid-domain-keys-and-dkim.html
Don't send spam! If you do all these things and still send spam, you'll still have troubles.
Monitor for bounces, possibly using VERP.
Make sure to provide a means to opt-out of your list.
Additional advice can be found here:
https://serverfault.com/questions/48428/how-to-send-emails-and-avoid-them-being-classified-as-spam
Here's an example of the SPF configuration I use:
https://serverfault.com/questions/122121/dns-zone-file-spf-configuration-to-support-sending-mail-from-multiple-servers-and
Newsletters especially can easily look like spam. You might consider using a service like MailChimp or similar that specializes in email marketing and mass emailing. They will make sure to tend to all the technical details, remove their servers from blocklists if they get blocked, and so forth. They also provide you with opt-out features, CAN-SPAM compliance, and more.
I've found the Spamtacular blog to have good information as well (it looks like they are having some technical issue right now - hopefully it will be online when you view this).