I don't understand this "reverse dns" thing at all.
So, I have a website - www.someurl.com, and I have an ip address - http://180.160.160.190 (fake).
Now, I want to setup a "reverse dns" thing, so that emails that I send out won't be marked as spam.
Questions!
why do i have to setup a "reverse dns" thing? What is it, and why do gmail, hotmail et al care about it?
all the examples online say I need to setup the "hostname" as mail.someurl.com (well, they say mail.domainname.com, but I cleverly solved for x). What the heck is a "hostname" and what is a "url"? The wikipedia page for hostname left me v. confused.
is a url a domain name? it sure isn't a hostname (i hope).
back to the mail.someurl.com hostname - why is it "mail" in the examples? Can I fecklessly set the value to "hello" or "mooseymooseymoose" (so it would be mooseymooseymoose.someurl.com)? Does it have any relevance to anything at all?
if i am sending emails out as no-reply#someurl.com, does that have any bearing on the first bit of the hostname? that is, should they come from "mail#someurl.com", given a hostname of mail.someurl.com?
cheers, andrew
It's an artificial requirement that was adopted under the assumption that spam servers wouldn't take the time to setup their rDNS (or wouldn't be able since they usually got setup in rogue environments like infected PC's), and legitimate servers would. There is no technical requirement to have a rDNS for the email protocol to work, and not every mail server does this check.
The hostname is the name of your machine within your internal network.
URL stands for uniform resource locator, it's the fancy name for stuff that looks like "http://www.google.com/page1/page2". a domain name is simply the base of the URL, for example google.com. It's always of the form domain.tld (domain name and top level domain like com, net, org)
Yes you can set it to anything you want. Mail protocol doesn't require you to hardcode the name to anything in particular. Ultimately, it's your domain's MX record that decides where the mail server handling its emails is located at, and you can point it to anything.
Not necessarily. Mail servers can send e-mails on behalf of several domains, a mail server isn't limited to sending emails from its hostname only. The "From" part of the e-mail header will tell the mail client where it's coming from.
Hope that helps clear up a few details.
Its to make sure that the email is coming from a verified source. Emails sent to anyone can display ANY email address on it, making it easy to spam and pish people. Thats why they use reverse DNS, to verify that the domain sending the email is yours.
Related
This is not an easy question because its a technique I have never seen before.
I recently received an email from a website I am subscribed and the email sender was something like this:
name#company-91e363c0cfc9.mail.intercom.io
I have a Saas software where users can send email marketing.
The problem is that the sender email is no-reply#domain.com for every one of them.
I was thinking about "what if" some of my customers sends junk and my domain gets blacklisted?
Looking at the technique Intercom is using I thought that it is a good way to solve the blacklist issue.
Let assume a customer sends spam, is the hole domain blacklisted (mail.intercom.io) or just #company-91e363c0cfc9.mail.intercom.io ?
I have the following questions:
What is the name of this technique/configuration.
Is it a good technique to solve getting the root domain
blacklisted ?
How can I configure this on my server?
Thanks.
They are create a sub-domain for each of their clients in DNS, as you can see by the MX Record Lookup of the domain you provided. When an email get sent out, they have an outgoing IP address on the email, which you didn't provide. The outgoing IP is going to blacklisted, it doesn't matter if the 50 sub-domains are different, the Outgoing IP (Sending IP) is going to get blacklisted. I don't think you're going to be able to working around an abusive customer, if the IP's are the same.
I spoke to some hosting companies that have similar issues and before they every allow a client to send mail, they need a clean report from this Mail Tester. But, even with a clean configuration and authentication, that doesn't prevent spam content from being sent. When that happens the IP owner has to address it, ultimately barring that customer from sending spam, if they don't correct the behavior.
You can always monitor your IP's for Blacklists and you should, but you're going to get a ton of abuse reports coming in from various providers, if it's a problem.
We are building a system that is, effectively, an email/calendar/contact client.
Users will provide us with their email address password (or other auth, eg oauth) and we will connect to their underlying email system.
"underlying systems" include:
Microsoft Exchange / Office365
GMail
Yahoo Mail
Apple email
Generic IMAP
Each of these systems have subtle (and not so subtle) differences in their APIs, especially to access calendar & contact data. Thus we need to know what provider the user is using.
But we would rather not ASK the user. We would like to figure it out (and at, least reduce the choices) automatically.
I've looked around for something that already implements this but have not found anything. I know it's mostly possible because Windows Phone does it pretty well (just enter username/pw and it does the right thing).
Before I dive in and start writing my own I want to ensure I'm not wasting my time if someone's already done it in an excellent way.
Know of anything like this? For this project prefer C#/.NET.
[EDIT: Adding potential algo]
Potential Algorithm:
Given email address & password
Extract domain name from email address
Try Exchange autodiscover. If successful done.
Use DNS MX records to find smtp host.
Do SMTP EHLO
Gmail responds with "250-mx.google.com at your service"
So if we see a "google.com" we are done.
Yahoo responds with 250-mta1257.mail.sk1.yahoo.com
So if we see a "yahoo.com" in the response we are done.
Apple responds with 250-xxxxxx-mac.com
So if we see a "mac.com" in the response we are done.
If none of the above
IMAP?
...
[EDIT: 5/18]
I built a prototype that uses methods that don't require auth (e.g. just MX/SMTP sluthing). Give it a try: http://bit.ly/KLZKxD
Algorithm seems reasonable. You will get best results running from unfiltered server (meaning it has direct SMTP outbound / doesn't run through a proxy). If running from client (mobile/tablet/desktop), then no guarantees as some ISP's pass SMTP through a proxy relay hence EHLO response is only for proxy.
You may want to do a port check for servers to verify expected protocol support (just a TCP connect may be sufficient but protocol handshake is preferable). Additionally, best to build up a database of verified SMTP and IMAP server mappings as there can be split names (e.g. smtp.domain.com and mail.domain.com) - discovering SMTP is easy, discovering outbound server(s) which usually also means calendar/contacts server, not so much (except for Exchange but only if autodiscovery is configured correctly).
If you can get your users to approve and assuming you have their username/password, you could try connecting to SMTP via MX record and sending an email back to your own address then checking through headers for useful info about the server (needs to be authenticated to relay). Users could alternatively reply to an email you generate in order to get the same server info.
Also ensure that you do your own DNS query and try each MX record or all primaries -- if the principal MX is down or DNS is poorly configured for equal weighting, you could end up hitting a smarthost / backup which may just be a dumb SMTP relay / store-and-forward and not give you the correct response.
TL;DR: No quick solution but a cascaded algorithm that trys and fails different solutions until one works / gives an expected result should work.
Most devices can auto detect the service by parsing the Whole e-mail address. Xyz#gmail.com would obviously be a gmail account. So for Apple, Gmail, Yahoo, Live, Hotmail etc you can easily program for.
For other domains, including custom, you can try this: http://www.exclamationsoft.com/exclamationsoft/netmailbot/help/website/HowToFindTheSMTPMailServerForAnEmailAddress.html
You can detect Google Apps For Your Domain accounts by examining the domain's MX records. If the primary MX record is ASPMX.L.GOOGLE.com, then it's GMail.
I created an implementation of this that has been used widely with some success: https://github.com/tig/Email2Calendar
This is used by both milelogr.com and freebusy.io.
I'm implementing an application in ruby on rails (although this is a minor detail) that needs to send emails. Everything works fine, but I'm surprised cause when the app sends a mail, as long as it's authenticated against the smtp server, the sender it's going to be whatever it's specified in mail from. My point is, I can authenticate in a smtp server with "myuser#mydomain.com" and "mypassword" and be able to send a mail in which the recipient would see whichever address I want as sender.
This doesn't make any sense for me, and I'm sure it can't be so easy. I know it's surely a completely silly question for most of you, but would really appreciate anyone could make it clear for me.
Cheers!!
You authenticate as a generic user, it is only an accident that your login name is similar to a mail address. And yes, usually you can send mail with any reverse-path (reverse-path is the address in the MAIL FROM SMTP command). This may be necessary, for example a list manager uses VERP and sends mails with many unique reverse-paths.
However, some mail servers and mail administrators do place restrictions on the reverse path and the address in the From header. Especially, if the server signs the message.
Moreover, if the receiving server checks SPF records, it is useless to impersonate a remote domain, even if it is allowed, because the mail will be rejected anyway (if the domain publishes an SPF DNS record).
I've had a good search on Google but can't find the answer sorry...
We're an Australian company who use a .com address as our primary contact point. Unfortunately sometimes people email to foo#ourdomain.com.au and so the email bounces.
I know I can manually create entries to forward the .com.au addresses to their .com equivalent, but it's not a particularly viable solution longer term.
Is there a way to automatically do that mapping at a server level? We have root access so I can set up whatever is required in that regard.
To re-iterate, everytime someone sends an email to:
foo#ourdomain.com.au
it needs to forward to
foo#ourdomain.com
and I'd prefer to automate the mapping as email addresses are added / removed quite regularly.
We are also using PLESK if that makes a difference.
Thanks...
Sounds to me like you don't need to forward at all. Just set the MX record for ourdomain.com.au to be the same as the MX record for ourdomain.com. Then configure the mail server to accept mail for both domains. The only case in which this isn't viable is if there are actually legitimate .com.au addresses that need to be handled by a separate mail server.
When developing an application that sends out notification email messages, what are the best practices for
not getting flagged as a spammer by your hosting company. (Cover any of:)
best technique for not flooding a mail server
best mail server products, if you were to set up your own
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
any other lessons learned
not getting flagged as spam by the receiver's client? (Cover any of:)
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
best SMTP header techniques to avoid getting flagged as spam when sending emails for users (for example, using Sender and From headers together)
any other lessons learned
An additional requirement: this application would be sending a single message to a single recipient based upon an event. So, techniques for sending the same messages to multiple recipients will not apply.
best technique for not flooding a mail server
not a lot you can do about this beyond checking with your mail server admin (if it's a shared hosting account / not in your control). but if the requirement is one email to a single recipient per event, that shouldn't be too much of an issue. the things that tend to clog mail systems are emails with hundreds (or more) of recipients.
if you have events firing off all the time, perhaps consider consolidating them and having an email sent that summarizes them periodically.
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
you can accomplish this by using the "Reply-To" header, which will then have clients use that address instead of the From address when an email message is being composed.
you should also set the "Return-Path" header of any email, as email without this will often get filtered off.
ex.
From: me#me.com
Return-Path: me#me.com
Reply-To: auto#myapp.com
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
this is all highly dependent on how much ownership you have of your mail and DNS servers. spf/sender-id etc... are all DNS issues, so you would need to have access to DNS.
in your example this could present quite the problem. as you are setting mail to be from a specific user, that user would have to have SPF (for example) set in their DNS to allow your mail server as a valid sender. you can imagine how messy (if not outright impossible) this would get with a number of users with various domain names.
as for reverse DNS and the like, it really depends. most client ISP's, etc... will just check to see that reverse DNS is set. (ie, 1.2.3.4 resolves to host.here.domain.com, even if host.here.domain.com doesn't resolve back to 1.2.3.4). this is due to the amount of shared hosting out there (where mail servers will often report themselves as the client's domain name, and not the real mail server).
there are a few stringent networks that require matching reverse DNS, but this requires that you have control over the mail server if it doesn't match in the first place.
if you can be a bit more specific i may be able to provide a bit more advice, but generally, for people who need to send application mail, and don't have a pile of control over their environment, i'd suggest the following:
make sure to set a "Return-Path"
it's nice to add your app and abuse info as well in headers ie: "X-Mailer" and "X-Abuse-To" (these are custom headers, for informational purposes only really)
make sure reverse DNS is set for the IP address of your outgoing mail server
first a quick correction to the previous
return-path: is a header added by recieving system based on the envelope-sender of the incomming message
for spf to work the return-path/envelope-sender needs to be yourapp#yourdomain.com
and ensure the spf record for yourdomain.com {or if per-user spf} for yourapp#yourdomain.com allows mails to originate on the server that hosts the app/sends the email
this envelope-sender is the address that will recieve all bounces/errors
now sender-id is different entirely it checks the return-path/envelope-sender
and the
from: address {stored inside the message}
if sending
from: hisname yourapp#yourdomain.com
reply-to: hisname hisaddres#hisdomain.com
this will be a non-issue
if sending
from: hisname hisaddres#hisdomain.com
it will be and you must add a
Resent-From: hisname yourapp#yourdomain.com
as this specifies to ignore the from: for sender-id checks use this instead as it has been sent by you on his behalf
now for the other bits that are worthwhile
ip's mentioned are your mailservers
a have your ip's ptr point to a name that also resolves to the same ip
FQDNS
b have your server helo/ehlo with whatever.domain.com where domain.com is the same as the domain of the name in step A {not the same name for resons below}
c have that helo/ehlo servername also resolve to the ip of your server
d add the following spf record to that helo/ehlo name "v=spf1 a -all"
{meaning allow helo/ehlo with this name from ip's this name points to only}
e add the following sender-id lines to the helo/ehlo name {purely for completeness
"spf2.0/mfrom,pra -all" {ie there are no users#this-domain}
f add the following spf to the FQDNS-name and any other hostnames for your server
"v=spf1 -all" {ie no machines will ever helo/ehlo as this name and no users#this-domain}
{as the fqdns name can be determined by bots/infections its better to never allow this name to be used in helo/ehlo greetings directly it is enough that it be from the same domain as the helo/ehlo identity to prove the validity of both}