I wish to code a little service where I will be able to send an e-mail to a specific address used by my server to send specific commands to my server.
I'll check against a list of permitted e-mail addresses to make sure no one unauthorized will send a command to the server, but how do I make sure that, say, an e-mail sent by "mrzombie#thezombie.net" really comes from "thezombie.net"?
I thought about checking the header for the original e-mail server's IP and pinging the domain to make sure it is the same, but would that be reliable?
Example:
Server receives a command from mrzombie#thezombie.net
mrzombie#thezombie.net is authorized, proceed with checks
Server checks "thezombie.net"'s IP from the header: W.X.Y.Z
Server pings "thezombie.net" for it's IP: A.B.C.D
The IPs do not correspond, do not process command
Is there any better way to do that?
If you can solve this for generic e-mails, you solved the problem of SPAM.
Given that the mail headers are free form text in which anyone can claim anything, you can't do any sort of authorization nor authentication based on the mail headers. Your best bet is to authenticate the content, and there are protocols for that like S/MIME or PGP. They rely on cryptography for authentication and your server will be able to verify that the content is signed by a certificate you trust. But you'll move the burden on the mail sender that will have to send a properly signed message. Most mail readers though support adding digital signatures to content.
but how do I make sure that, say, an
e-mail sent by
"mrzombie#thezombie.net" really comes
from "thezombie.net"?
You also may want to look at Sender Policy Framework, as it is at least in part trying to provide a means of verifying that email was sent from authorized domain servers.
Also, serverfault.com may have some helpful answers for you since it is a networking- and server-related question.
You can use SPF to verify that a given IP is/is not authorized to send email on behalf of a particular domain (assuming that domain implements SPF, of course), but that only gets you so far. For example, it may not prevent another user at the source domain from impersonating the authorized user.
Authenticating the content with a digital signature is really the best way to go.
Related
I don't have any technical problems, but I have a question that I would like to be answered out of curiosity.
Here is my current understanding of how email works:
One of the privileges of having your own domain is that you can hook it up to IMAP/POP3/SMTP servers and use them to send and receive messages to and from "anyone#yourdomain.com". With spam being such a problem, however, the SMTP server that you use to send messages must add a bunch of headers (DKIM, SPF, etc) to each message that you send in order to prove that the SMTP server has the authority to send emails from that domain. The receiving SMTP server can cross-check those headers with DNS records that it finds to verify the legitimacy of the email message.
So if you want to send emails with your domain cheaply, you can use Gmail's "Send Mail As" feature. I followed this help article to get mine working: https://support.google.com/domains/answer/9437157
Note: I unchecked the "Treat as an alias" option during the setup.
But wait... no additional DNS configuration required? I have my domain registered with Cloudflare, and there are no entries related to Google in there.
There is this step in the setup process:
But it seems that this only for Google to prevent you from using their servers to send spam. What is stopping Google from impersonating any email address they want? Why do receiving SMTP servers trust an email from "anyone#yourdomain.com" if Google's SMTP servers have no way of adding legitimate SPF/DKIM headers?
The short answer is that nothing prevents Google from doing this, and that DMARC was created for exactly this case.
There is nothing that stops Google from impersonating any domain. However, there are things receivers can (and should) do when they receive an email which isn't send from the server indicated in the From: field.
Try sending an email from the alias you just added to a different #gmail.com inbox. You will see that it says via gmail.com behind the sender email address. But other email receivers might do more: flag this message with red exclamation marks and scam warnings, throw it into spam or even deny receiving it completely. Gmail probably has some hardcoded trust, but try doing this from your own SMTP server and the above will very likely happen.
As you say in your question, you can authorize your emails by marking gmail.com as an authorized sender with SPF (which protects against forging from other domains, but doesn't stop Google), or even sign your emails with DKIM (not possible from Gmail UI, but you can do this in some email clients or send email with a custom Python script like me; Google can't do this without knowing the key).
However, that only solves one side of the problem – authorizing legitimate email messages. But what if an SMTP server still receives an unverified email? What if they have previously received an email from the same sender which was DKIM signed? What if DKIM passes, but SPF fails?
Because the behavior in that case is largely unspecified, and also the sender wants to check if their DKIM/SPF authorizations are actually working, and if anyone is attempting to spoof them, another standard was created: DMARC. It introduces another DNS TXT record where you can say what checks are required to pass, what to do if they fail, and also what basic analytics should the receivers report to the owner of the domain.
Of all webmail client providers, Google's Send mail as is actually the most well-implemented for a variety of reasons.
First of all, how it works is not different from when you set up POP3 or IMAP using a mail client like Outlook or Thunderbird. You have to specify the domain and port where you receive emails from, and the domain and port where you send emails from. For example, Google's incoming and outgoing servers for IMAP are as follows:
imap.gmail.com:993
smtp.gmail.com:465
The Send mail as feature is a partial implementation of that. It only implements the outgoing part.
How mail clients like Outlook and Thunderbird send emails, is basically that it sends the email to the outgoing mail server, and the outgoing mail server then sends the email. Usually, outgoing mail servers will require some sort of authentication, and will allow authenticated users to only send from specific email addresses.
Gmail works the same way. The outgoing mail server is the one that has to pass the SPF and DKIM tests, not Google's servers.
No other webmail clients do this. Hotmail used to do this, but they recently removed the feature. Now, the option is very difficult to find, and they just rewrite your FROM address and sends your email from Hotmail's SMTP server, which creates delivery problems.
They don't provide you with the option to send emails from another SMTP server, because this allows people to very easily set up virtual mail servers that can send emails under a domain of your choice, but use say a typical free Hotmail account to store incoming mails. This takes away business from their paid services, because both Hotmail and Gmail sell the option to host your company emails. I'm sure Google also knows about this, but it is really awesome of them to still keep the option available to free Gmail users.
If you want to learn more about virtual email servers, you can check out this article here: https://blog.terresquall.com/2022/01/setting-up-a-virtual-postfix-mail-server-part-1/
Given an email address, like "user#example.com", I'm trying to ascertain information about the email server they use, information like:
Domain
Port
Uses TLS
Currently, I can split the email address into two parts (for instance user and example.com), then do a MX lookup on the domain in order to attempt to ascertain the mail domain used:
dns.resolveMx(hostname, callback)
However, several hosts seem to use other servers than those (for instance, JustHost encourages all their domains from example.com to justXX.justhost.com in order to provide them with TLS) and attaining those is proving to be tricky.
The port is okay, as long as they use a default port, else as far as I can see it's impossible and TLS is easy to work out as long as I have both the domain and the port in order to contact the server.
Since all these methods seem unreliable at the best of times, are there better methods of ascertaining this information? This is in relation to making a mail client, which attempts to logon to the mail server to retrieve emails, and using the SMTP protocol in order to send emails from that server.
The only information that you can rely on is what is available in DNS. This is all of the info that is needed to send mail for a given address.
If you want to receive emails then it's an entirely different story. You didn't mention which mail server you need. The server that gets the incoming email? The server that lets user send email? The server that lets users download their emails? I'm assuming that you want the server that you can send email for that domain to - what is available as MX in DNS.
You didn't mention why you need that info but if you want it so you could send emails for those domains then you can sonsider using a transactional email service like or Mailgun, Mandrill or Amazon SES because it will handle all of those details for you. But you didn't say what is the purpose of getting that info so I don't know if that will help you, I'm adding it just in case.
I have signed up with Google Apps, I am using a third party SMTP Server to send the emails from the web app, Emails are reaching inbox for all the email clients (yahoo, gmail, hotmail...)
But Emails sent to my domain (mydomain.com) are reaching SPAM, This is happening only for my domain Which is google apps account domain. The solution to the problem is the sender must be in the contacts of the receiver. So its a overhead involved in adding the sender in the contacts before receiving the mail. This is not automated.
NOTE: Mails sent from <xyz#mydomain.com> to <abc#mydomain.com> are reaching SPAM. It means, Its happening only when the sender and receiver belongs to same domain.
ASSUMPTION: ALL the emails will be sent from mydomain.com .
So, I want to write a script using google apps script So that when a mail arrives from mydomain.com (having FROM address belongs to mydomain.com), The script must execute and add the senders emails address in the contacts. So it will avoid the spam rate.
I am very new to google apps script, Please help me doing this, Or if any better solution is there please feel free to post.
Vinay,
It sounds like you may have an incorrectly configured SPF record. Please see this article:
https://support.google.com/a/bin/answer.py?hl=en&answer=33786&topic=2759192&ctx=topic
Email that has a mydomain.com sender address, needs to come from a mail server listed in your SPF record or risk being sent to spam.
By chance, has Contact Sharing been enabled for your apps domain? I'm just offering this as an hunch that might help rather than a specific solution to your problem.
If this doesn't help, its a straightforward but non-trivial problem to add all your domain accounts to each others contacts list (and keeping it synced over time), but you'll be leaning heavily on a version of the Contacts API rather than plain Apps Script because the Contacts service only operates on the contacts of the user executing your script.
I'm working on a web-based application, and looking to integrate each user's e-mail (gmail, yahoo, etc.) into it. I'd like to do an automatic sync (side detail: selective to specific e-mail addresses) of inbox and sent messages, i.e. any messages sent through the application will appear in the user's e-mail, and vice versa; any messages received in the application will appear in the e-mail, and vice versa.
My question: I realize this will probably involve IMAP. Is there a way to go about this without storing the user's e-mail passwords? I'm open to any language, infrastructure, etc.
If there's really no way around storing the passwords, would MD5 be sufficient? Any other thoughts would be greatly appreciated.
you would need to find an OAuth-based API for accessing the email provider. this would allow the user to authenticate themself, provide you with an access token for later use.
I believe you can do this with Gmail, Yahoo (see links)
A situation where this might arise is a private messaging system on a forum. A user might want PMs forwarded to their main email so that they don't have to remember to check the inbox on your site as well as their main email. Then when users reply to those messages, you want the reply to go as a PM to another forum user.
Forwarding PMs as emails is trivial. In order to allow replies, you need to have the email server on your site parse out some information in the email that indicates which user it should be forwarded to as a PM.
If you really want to allow a user to access their entire GMail inbox from within the interface on your site, rather than just messages that went through your site anyway, then you are facing a much larger task.
Let's assume that i use a telnet session and send an email with address alice#domain.com to bob#domain.com but in fact i am charly#domain.com...
On alice#domain.com i have a WCF web service running that's monitoring that specific mailbox using Exchange Web Services...
How can i tell that the message from bob#domain.com actually came from charly#domain.com?
I am using Visual Studio 2010, with .NET 4.0 and EWS managed API 1.1
The server is configured to use SSL and i have Exchange Server 2007 SP1.
i tried the two properties "Sender" and "From" but they are identical and both point to bob...
nothing in the message header actually points to charly... everything points to bob... any ideas? things that i might have overlooked?
If you want to make sure that identity spoofing is not possible using an email service, you can use cryptographic signatures. PGP / GPG and S/MIME are common technologies in use to implement this.
This requires every mail sent from alice#domain.com to be signed by her with a secret. The key or certificate she uses to do this must be trusted by your webservice. Your webservice can verify that a mail has really been sent by Alice by checking the validity of the signature. Only someone who possesses the secret of Alice can create such a valid signature. If the signature is wrong or missing, your webservice can trigger an alert.
Should the real Alice forget to sign an email, your service will trigger as well, because it cannot tell if it really was Alice who sent that mail. You also need to make sure that the secret in use can only be accessed by Alice. If you need further informations, you should read up on public key cryptography.
I don't think you can detect such practices with EWS Managed API at least I don't see anything that could be helpful in this situation. Unless valid sender is recognized with use of some cryptographic signatures or you can somehow mark messages from valid senders with your own extended property that only you (your software) create and uses you have to believe that mail was sent by whoever is showing up in Sender or From property