Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have a domain mydomain.com
I need to use this domain on multiple servers.
I have greengeeks shared hosting as well as AWS with few EC2 machines for my web applications.
mydomain.com is hosting a marketing site via greengeeks hosting and it also provides my email server.
I want one sub domain app.mydomain.com that will point to one of my ec2 instance, another subdomain appadmin.mydomain.com point to another ec2 instance, What is the best way to setup domains and sub-domains like this. (currently i am using different domain (mydomain.org) for my aws instance, which isn't elegant)
As my mail server is on greengeeks, and I programatically send email from my ec2 app server using an email id app#mydomain.com, some email clients shows warning as "cannot verify email origin" and some pushes it in spam folder, is there a solution to it, I read about MX and SPF record but I am confused how to create them and where to put them.
Thanks,
K
I want one sub domain app.mydomain.com that will point to one of my ec2 instance, another subdomain appadmin.mydomain.com point to another ec2 instance, What is the best way to setup domains and sub-domains like this. (currently i am using different domain (mydomain.org) for my aws instance, which isn't elegant)
I'm not sure what the question is about. You should be able to make an a-record for each site. One for app.mydomain.com and another appadmin.mydomain.com.
As my mail server is on greengeeks, and I programatically send email from my ec2 app server using an email id app#mydomain.com, some email clients shows warning as "cannot verify email origin" and some pushes it in spam folder, is there a solution to it, I read about MX and SPF record but I am confused how to create them and where to put them.
SPF records are made typically made in either TXT-records, or SPF-records if your DNS provider, has a specific section for this. Both should work.
TXT records are nothing more than a record, with some text in it, but it can be interpeted as a SPF record, if specified as one (see part 1).
SPF entries are a collection of trusted IPs/hosts, that a spamfilter or mailserver can use to validate a the IP adress of the sender.
In the email message header, it will always say where the email was sent from(cant be spoofed to my knowledge). A spamfilter will compare the sender to the SPF entries of the specific domain and decide weather to reject the message or accept it.
Lets look at one example.
v=spf1 include:1.mailserver.com include:2.mailserver.com ip4:99.99.99.99 include:relay.anothermailserver.com ?all
Part 1
Specifies the version of SPF that you're using. SPFv1 should be able to do the trick for you.
v=spf1
Part 2
You specify the mailservers/IP subnets that should be allowed to send from your domain.
include:1.mailserver.com
include:2.mailserver.com
ip4:99.99.99.99
include:relay.anothermailserver.com
Part 3
Specifies weather to mark message as (~)SoftFail, (-)HardFail, (+)Pass or (?)Neutral, when the sender is not specified in your entries.
The receiving mailserver decides, weather to reject or accept a message based on their own policy. Meaning that some spamproviders/mailservers will reject a softfail, and some still may accept it.
Generally a hardfail should get rejected.
?all
If you need some material on this subject, id sugest www.openspf.org/SPF_Record_Syntax for the syntax.
Also you can use mxtoolbox.com which has a great tool, that specifies the different parts of a record.
As for the MX records. The MX specifies the receiving mailserver and in which order it should try to send the messages to them.
Example
Sending a mail to administrator#mydomain.com
MX record for mydomain.com
Priority = 10 / 99.99.99.99
Priority = 20 / server1.mymailserver.com
Priority = 30 / server2.mymailserver.com
Priority = 5 / myloadbalancer.mymailserver.com
Here it will look up the MX-records for mydomain.com, find the MX with the lowest priority and send the message to that IP/Host. If it doesnt get an answear from the server, it will proceed to try and send to the next MX-entry. If the message is accepted by receiving mailserver, then the mail goes through. If no answer is given by any of the MX-entries, it will notify the sender address, that the message could not be sent.
Please let me know if i missed something.
/AG
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I use SendGrid and I have 2 dedicated IPs... My website sends its emails using SendGrid.
At the same time I use G Suite and I personally send my emails using G Suite (Google Workspace)
I want to setup DKIM and SPF records. SendGrid documentation has an option called Automated Security:
Automated security allows SendGrid to handle the signing of your DKIM
and authentication of your SPF for your outbound email with CNAME
records. This allows you to add a dedicated IP address or update your
account without having to update your SPF record.
and later on...
When Automated Security is On, SendGrid generates 3 different CNAME
records. In a later step of setting up domain authentication, you give
these records to your DNS provider, and then you verify that they
upload correctly.
If you select Off, we generate 1 MX record and 2 TXT records. In a
later step of setting up domain authentication, you give these records
to your DNS provider, and then you verify that they upload correctly.
So When Automated Security is ON I won't need to add any SPF and DKIM record, instead I have added the 3 CNAME records that is required for Automated Security...
On the other hand I am also using G Suite and G Suite wants me to add DKIM and the following SPF record:
v=spf1 include:_spf.google.com ~all
From what I understand, the above SPF record means that _spf.google.com is the only server that should be sending my emails...
So my question is: Is adding G Suite SPF record conflicting with SendGrid Automated Security? My SPF record is saying the My SendGrid's dedicated IPs are not allowed to send email?
Imagine Yahoo mail server receives an email from one of my dedicated IPs (SendGrid)... how would Yahoo know that I am using Automated Security and the SPF record is handled by SendGrid? Because If Yahoo checked the SPF record, the SPF record is telling it that only _spf.google.com is allowed to send my emails?
Just a note: Your question would probably do better at the Server Fault forum.
To answer you questions:
No the SPF record where you list G Suite is not conflicting with your SendGrid setup.
What is important to understand is: SPF says absolutely nothing about who is allowed to send emails FROM your domain. SPF authenticates the Return-Path address instead, and you're creating a subdomain for the bounce messages (what the Return-Path header is used for) with the CNAME delegation records in "Automated Security".
So, basically, Sendgrid is asking you to create a sub domain for them, e.g. em123.yourdomain.com by means of CNAME record. You delegate that subdomain over to them, targeting your personal Sendgrid tenant zone in DNS, where they create an SPF record and MX record at the root of that zone. A typical email from Sendgrid will then look like this:
from: you#yourdomain.com, Return-Path: bounces#em123.yourdomain.com
Thus, the receiving server will check the SPF record at em123.yourdomain.com to see if your IPs are allowed.
The other two CNAMEs are for the DKIM selector records. They point to TXT records that Sendgrid manages and rotates periodically.
So why not have Sendgrid use their domain in the Return-Path and not bother with the CNAME setup at all?
DMARC demands that your Return-Path domain aligns with your FROM domain, OR that the domain used in your DKIM signatures aligns with your FROM domain. Preferably both.
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 4 years ago.
Improve this question
I have recently acquired a domain name via Google Domains. I have set some configuration to have it point at an OpenShift application via Cloudflare. Cloudflare requires me to set their DNS servers, which I did in Google Domain.
At Cloudflare, I have created two CNAME records (and nothing else). One is an alias from my mydomain.com to some.url.at.openfshit.com, and the other is from www to mydomain.com.
Yet, within Gmail Domain, I have also set an email using my domain name which is to be forwarded to a private email. But, I don't receive any emails when testing.
I am wondering whether I could have my emails forwarded properly. Is it a matter of creating a MX record at Cloudflare? If yes, with what configuration?
P.S.: I have set a MX record using instructions available here, but I get:
Delivery to the following recipient failed permanently:
contact#mydomain.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain chartvibes.com by aspmx.l.google.com. [2607:f8b0:4001:c20::1b].
The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/answer/6596 p123si522326ioe.111 - gsmtp
The MX records you're using are for G Suite accounts. You can still forward emails with Cloudflare and Google Domains, but you'll need different MX records. As Overdrivr pointed out in a comment below, you can find your MX records in the DNS settings in Google Domains. Once you're in the DNS settings page, look for a collapsible panel called "Email forward" under the "Synthetic records" section. You should see something like this
Then, make a backup of your Cloudflare DNS setup, erase all MX records and add the ones listed in your account using the number right before the mail server (e.g., 5, 10, etc.) as its priority.
It might take a few minutes for the changes to take effect. If you try to send an email right after changing the records, it's likely that you'll get a message saying that the address could not be found, but it'll have the G Suite mail server in the Remote-MTA field (aspmx.l.google.com) instead of gmr-smtp-in.l.google.com. If this is the case, just wait for a few more minutes and try again
I'm not sure if you already have a solution to this, but if you do, I'm interested in how to do it too. Could you please post your solution here if you find one ?
The bad news is, it cannot be done because the way Google Domains work. Google Domains has email forwarding, but it works only when you're using Google's DNS servers. It's the same with all hosting services or whatever they're called.
I think Google just has an email forwarding service that can forward upto 100 alias email addresses per domain to an actual email address. But the actual email address has to exist somewhere. The ones you set up in the Domains console are just aliases or forwarding instructions.
For Cloudflare email forwarding to work, you need to use the SMTP servers where the actual email addresses exist, but since Domains has no actual email service servers, the emails sent out are failing with email account does not exist. The instructions you mentioned are for the Google Apps, which have actual email/gmail addresses set up, but they cost $5/user/month.
The only solution that I can think of to get around this issue is to have our own mail server, and have cloudflare point to those, and then forward/deliver the emails from that mail server.
Hope this helps.
EDIT :
I probably didn't research this well enough before, but looks like people are getting around this issue by using a third party email forwarding service called mailgun
The actual article describing how to use it is on lowendtalk
Some discussion surrounding it is here
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
Someone is sending spam emails and is making it look like it was sent from my domain. How can i stop this email spoofing via cpanel. I read about SPF somehwhere.
Here is what my SPF in cpanel says
Your current raw SPF record is : v=spf1 +a +mx +ip4:ipaddress -all
What can i do to prevent this?
There is nothing you can do to stop them from sending email that is spoofed. You can send an email and have it look like it's coming from anywhere, and your outgoing email server (if configured to accept it, which spammers obviously would) and it will accept it. Adding an SPF record might reduce the number of those emails received by people.
You need to add (or append) to a TXT record in DNS.
v=spf1 include:your.email.domain.here -all
You can include more domains by adding another include: like:
v=spf1 include:blah1.blach1.com include:blah.blah.com -all
Hope that helps! Email is basically the most insecure protocol in existence.
You absolutely CAN stop spoofing. Have been doing it for 30+ years (before cpanel, etc.).
Regarding spoofing-- require all your users to authenticate before sending, this is the easiest way to stop spoofing on sendmail (see below for difference between spoofing and forgeries). If you are trying to block forgeries there are tools in the CPANEL (WHM) interface for require FQDN, EHLO, DKIM, etc. and other settings that will help you with this.
Also, check this thread out: https://www.webhostingtalk.com/showthread.php?t=669800
For more info on how to stop it on non-cpanel systems, continue reading. The concepts will help you understand what to change on cpanel systems as well.
The key rule to fight spoofing is that no email going through your MTA that is not on a "trusted" (e.g., internal) network should be allowed to have the sending and receiving domains be the same. Alone this will stop all spoofing. Once this rule is in placed, you add 2 more rules. The first says that internal "trusted" networks are exempted from this rule (thereby making external networks affected). The second rule is that any external connection that authenticates (username/password, etc.) is exempted from this rule. That allows your traveling sales team to send/receive email through your corporate server.
With sendmail you must require all connections to send a FQDN and that all FROM/TO address be fully qualified (so you can check the domain part).
In sendmmail.cf:
PrivacyOptions=needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings
By default in Sendmail 8.9 and later relaying from any network that is not considered "localIp" is denied via the checkrcpt() routine. So external email should only be "inbound" (unless being authenticated) and it should not have a sending domain matching your domain (unless authenticated).
Forging vs. Spoofing
There is a lot of confusion about "forging" and "spoofing". Forging is when someone sends an email claiming to be from one domain but they actually are not (such as someone pretending to be paypal). Spoofing is when an email outside of a network (e.g., outside of a business firewall) is sent to someone inside the network and both the sender and recipient have the same domain. This should never happen without the outsider being required to use authentication to bypass rejection. The reason is, that if you control an email network nobody outside your network should be originating email on your behalf without you knowing about it. If you know about it then there are various ways to adjust settings to allow it. But adjusting MX, SPF records etc. to stop spoofing is wrong. That is for identifying and stopping forgery.
Before we talk about solving spoofing in more detail, the best way to block forgeries is:
require EHLO with fqdn verify sender PTR record matches and
if not verify SPF It would be nice to use Domainkeys/DKIM, but the RFC
states that if Domainkey/DKIM can't be valided you are supposed to
treat it as thought it isn't there (so invalid DKIM should be
ignored)... frustrating. If you do decide to block emails with
bad/missing DKIM you will block almost everybody using ON365 as it's
almost universally misconfigured.
Use your access map to block foreign countries, etc., from which you
never expect to get email
Update your firewall to block networks you know are a problem.
I have learned a lot over the years with some hard lessons as I have administered email for some of the largest clusters/networks/providers in the world and some of the most well known dot-coms. Email is not an island unto itself. It is requires a tight integration with your DNS and firewall team and basics such as split-horizon DNS, DMARC, DKIM, SPF and good clean A/PTR records are critical to help manage the flow and authentication of valid email. Do not allow anybody from the outside to connect to port 25 to relay email (unless authenticated). Only internal users should be able to send OUT and external users be able to send IN. If someone inside is sending to someone inside, then they are connecting on the internal mail-servers port 25 and it is "trusted".
The best configuration works like this (does not matter what your MTA):
mailserver is inside a physical firewall.
barracuda or other anti-spam server is also inside firewall or dmz.
port 25 into your mailserver is blocked from the outside, but
allowed to your anti-spam/spamfirewall device
your MX tree is set up so that your mailserver is the primary, but
because it is not reachable from the outside, everybody will fall
back to your secondary (which is your anti-spam device).
Only your anti-spam device or internal-trusted systems should be
allowed to connect to your mailserver directly.
Use your firewall to prevent any internal system from sending email
outside directly (unless you have a very good reason) and force them
all to go through your internal mailserver to get outside (this is
the number one way to prevent spam on the Internet and every ISP
should do it)
Also, if you are using exchange, this will break inbound email because exchange needs more MX detail SOOOO (and it's a good idea anyway), you need to create a domain-level MX to your mailserver at the highest priority, but you ALSO need to create host-level MX, as follows (exch01 is your primary mail server):
# IN MX 10 exch01.mydomain.com.
# IN MX 20 barracuda.mydomain.com.
# IN MX 30 tertiary.externalmxprovider.xyz
exch01 IN MX 10 exch01.mydomain.com.
exch01 IN MX 20 barracuda.mydomain.com.
exch01 IN MX 30 tertiary.externalmxprovider.xyz
barracuda IN MX 10 barracuda.mydomain.com.
Make sure this information is advertised both internally and externally in your DNS.
I also recommend using your spam firewall as an outbound relay for your corporate email so that you can prevent from sending spam going out (in case an employee's computer get's compromised). Just configure your internal mailserver to use the anti-spam device as your "smart relay" for outbound mail.
If you need help doing this please let me know. Happy to help. I'm happy to help with any email, dns, or firewall configuration issue (dmarc, dkim, spf, etcx.)
David
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 9 years ago.
Improve this question
We have a domain name(for instance example.com, register at GoDaddy ), and now we'd like to use our own custom email address (for instance contact#example.com), but we are not intend to manage the Email server related stuff, we just want to forward the inbox mail to Gmail or Outlook .etc account.
So someone write a email to contact#example, then we can check it within Gmail or Outlook.
How to configure all above stuff? Any complete tutorial can offer help?
With whom did you register your domain name? The ease/difficulty depends on this. The steps that follow assume your DNS registrar offers email forwarding. If they do not, the steps would be too involved to discuss here.
Incoming mail:
STEP 1. Arrange for your DNS registrar to forward your emails to Gmail
Even if you want Gmail to handle this domain's mail, the emails still need one of your DNS registrar's mail servers to reroute them. All this mail server will be doing is rerouting gerald#example.com to jerry#gmail.com, but without it, you'd be blindly sending emails to gerald#example.com to Google, and Google would not know to which of its users the mail is intended.
The short story is: log on to your DNS registrar's website and look for an "email" or "email forwarding" section where you can specify that you want forwarding enabled, and to which Gmail address(es).
STEP 2. Change the DNS registrar's MX Record to point to your DNS registrar's mail server
You might then also need to set the "MX record" for "example.com" to point to your DNS registrar's mail servers. It is likely your registrar will set this up for you, or at least provide instructions, when you configure your email. See, people who send you email will send it first to your DNS registrar, who will forward the emails to Google.
GoDaddy.com Help pages re: setting up Incoming mail Forwarding:
I gather you registered your domain with godaddy.com - they have a tutorial on how to set up mail-forwarding on this webpage. The tutorial seems fairly good. I do notice one confusing step: you should literally use 'smtp.secureserver.net' as the mx record, they make it seem like it's just an example. 'smtp.secureserver.net' is actually GoDaddy's server, and the article doesn't make that very clear.
If you want to see a walk-through, some fellow even made a video tutorial last year.
Outgoing mail:
STEP 3. (Optional) Log in to Gmail and change your reply-to address
You hardly need to worry about outgoing mail. This is because the email protocols let you choose any old "reply-to" address you wish. In other words, I can send you an email from "sjobs#apple.com" or any other email address, and all normal email clients will show that as the sender's address when they receive emails from me.
So, once you have your incoming mail set up, you may wish to tell your Gmail account that your outgoing emails should appear to be sent from 'gerald#example.com'. You can do so by visiting this section of your Gmail account settings:
"Settings" > "Accounts" > "Send mail as:"
Hope this helps!
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 11 years ago.
Improve this question
As per this question I asked previously on Google App Engine, if I have access to all the information in a standard email, not just the From, To, Subject, Body fields, but also all the headers and MIME information, how can I verify that two incoming emails with the same From address are actually from the same sender.
What I've considered thus far:
Check the IP address of the email's sending server
Check the DNS records of the email's sending server
Verify the sending agent of the email (i.e. web interface, Outlook, Thunderbird, etc)
Check the reply-to field
Etc.
I realize this is a complicated question (I'm sure companies like Posterous have spent tons of time on this problem). I'm just looking for a few criteria to get started preliminarily. Thanks!
Update:
The answers so far are really helping, but just to help them out, the context of my project is that I would be receiving tons and tons of email as a web app from my users. They would use their email as the primary way of inputting data into my system. This I why I made the Posterous analogy. The use case is very similar.
You're right that all of the headers together, and 'known good' email to compare to can help identify likely spoofed emails.
What you're developing would probably be at best a heuristic rather than an algorithm.
I'd consider weighting the fields by time-of-day and how close to 'known good' emails' time-of-day ...
Also, if the 'known good' emails are structured differently than the suspect; i.e. Inline images, html, shortened url's, etc.
Why not run the emails through spamassassin or some such filter that will attach a bayes score. You can then just read that score. It will save you reinventing the wheel.
You could bayes score the email against a database of all previous emails from the individual.
There is also looking up the Sender Permitted Framework and DomainKeys, which SpamAssassin can do for you.
Probably not practical but something that would work:
When an incoming mail arrives, have a "reply to sender" function and simply ask if they sent it. This could be in the form of a confirmation link that is automatically generated or something.
But since I don't know the specifics of the project this may not be practical... like if you had to do this multiple times for each user, no one would put up with it.
Just to compliment my brothers posting earlier:
Not knowing the context under which you want to analyse this, and being very general I would suggest your first port of call is SPF or DomainKeys in order to limit the possibility of email coming from a rogue source being accepted. I would also recommend using only one SMTP server with SSL security. I do this and travelling worldwide I have rarely been in a situation I couldn't send mail and in those cases the only thing that did work was webmail (no safe local SMTP).
Additionally to that: if you are verifying mail is really coming from yourself then you could also use PGP tools to sign your mail upon sending and then filter any mail that didn't have a valid signature. Enigmail in Thunderbird is a good source of automatic signing and there are plugins for Outlook as well.
After that if you really want to do a more forensic job on an email then you could use a Spam Bayes to score the email against a database of previous emails. You would build up a database of tokens around the non-unique data (excluding entries such as "To:") and then score the email for the probability that it is like the previous emails. In theory you should score very highly for any mail.
Obviously I don't know your situation, but I think that there are many techniques but sometimes it is easier to go to the root of the issue than try and fix it down the line.
Update
Based on the context supplied:
I would consider using "Address Extensions" this is where your user can send mail to an address which contains a reference using the email address: emailname+extension#domain.com
GMail and many other servers support delivery of email with a +extension# through to the correct emailname#domain.com without hi-jinx. You could get the user to deliver mail with a unique ID as the extension and that way you would know it had come from them and they would feel more special. Obviously someone could steal their unique code by sniffing their outgoing or your incoming mail but that is always possible and if someone can do that they can probably inject mail as well.
If you really just want to go down the analysis route then I would suggest just using the reverse of a SpamAssassin per-user Bayes match. Where you compare every mail to a database of mails from a sender (instead of the traditional matching of mails 'to' an account). Remembering that once your database is polluted with a false positive you will have to remove the false positive or risk the integrity of the matching for that sender.
Maybe look into using Sender Policy Framework. It might not be exactly what you are looking for but it might help.
Briefly, the design intent of the SPF record is to allow a receiving MTA (Message Transfer Agent) to interrogate the Name Server of the domain which appears in the email (the sender) and determine if the originating IP of the mail (the source) is authorized to send mail for the sender's domain.
Ripped from wikipedia:
Sender Policy Framework (SPF), as
defined in RFC 4408, is an e-mail
validation system designed to prevent
e-mail spam by addressing a common
vulnerability, source address
spoofing. SPF allows e-mail
administrators the ability to specify
which Internet hosts are allowed to
send e-mail claiming to originate from
that domain by creating a specific DNS
SPF record in the public DNS record.
Mail exchangers then use the DNS
record to verify the sender's identity
against the list published by the
e-mail administrator.