Security issue: local domain delivery has higher priority than DNS configuration

Problem reported by Webio - 4/20/2015 at 5:43 AM

Submitted

Hello,

I'm almost sure that I've send information about that on previous forum but I can't confirm that. Anyway I would like to discuss about this IMHO big security issue with SmarterMail community. Issue is simple and it can cause serious problems for hoster.

Example scenario: somebank.com domain exists on remote location where somebank.com DNS MX,TXT,SPF records points to this remote location. Local SmarterMail user created domain somebank.com locally and is configuring catch-all account. Guess what? All local messages being sent from local recipients to this domain are being delivered locally to this catch-all account. DNS settings are not being taken under consideration during message delivery. I'm not sure how other think about but for me it is a serious bug. SmarterMail admin can add forbidden domains in Security -> Reserved Domain Names (https://help.smartertools.com/SmarterMail/v13/Default.aspx?qq=%2fsmartermail%2fv13%2ftopics%2fsystemadmin%2fsecurity%2fadvanced%2freserveddomain.aspx) but c'mon there is no way that all domains can be covered this way.

Regards

33 Replies

Reply to Thread

Steve Reid Replied

4/20/2015 at 7:43 AM

I agree this is a big issue, smartermail should always use dns

Bruce Barnes Replied

4/20/2015 at 10:44 AM

Great catch, Webio!

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

Webio Replied

4/20/2015 at 12:09 PM

I've only found something like this in my mail history from previous forum:

Please Help - Multiple Servers, DKIM - Disabling Local Delivery

Did you ever find a solution this this? I think SM should send mail to the MX records - not to itself. That's especially true when setting up a new domain for a customer - I can't send them an email since it goes to our SM server instead of their current mail server at another hosting company (where the MX records point).

If you can change the web app you can make it use a specific outgoing server (your primary server) - but that does reduce your redundancy.

One more thing found elsewhere:

http://forum.winhost.com/threads/smtp-fails-when-email-hosted-elsewhere.7619/

"That pretty much has SmarterMail and any mail server works. It will always look internally first before it sends out the email."

from ... 2010

Another forum:

http://community.discountasp.net/threads/split-domain-rounting-message-routing-for-shared-address-space.16813/

from 2012.

I just don't believe that someone had not reported this as a security issue. I was almost sure that I've mentioned about it in some of my tickets but I can't find it.

Joe Wolf Replied

4/20/2015 at 5:30 PM

SmarterMail always considers itself as the authoritative server for any domain on the server. The next highest priority is the Hosts file, and then DNS. SmarterMail has been this way since the very early versions (if not all versions).

The statement "Local SmarterMail user created domain somebank.com locally and is configuring catch-all account." in the OP confuses me. How could any local user create a domain? It takes an Admin to create a domain, and you should have catch-all disabled server wide (there's no valid use for them anymore and just open your system up for a DDoS attack... I could shut down your server anytime I wanted to do so).

The only people that could create such a scenario is a System Administrator, and if you have any of those that you don't trust 100% then you have a problem.

Even a Domain Administrator cannot add a Domain Alias that doesn't have a MX record pointing to your SmarterMail server. So even a Domain Admin could not accomplish what you described.

-Joe

Thanks, -Joe

Webio Replied

4/20/2015 at 9:28 PM

I'm not sure if you have taken under consideration hosting scenario where users are managing their SmarterMail accounts using hosting control panel. Catch-all account is something additional to this secuirity issue. Even without catch-all disabled users can create mailboxes and mailaliases in domain which they are managing.

Webio Replied

4/20/2015 at 9:29 PM

Ok now .. this worries me a lot. Why status of this post has been changed to "Not a problem" without any discussion.

Joe Wolf Replied

4/20/2015 at 9:36 PM

I have no idea what Control Panel would let a User or even a Domain Administrator create a Domain on SmarterMail. It takes an Admin to do so. I have servers with cPanel and DiirectAdmin but I generally don't use any control panel on a Windows box. Even a Domain Administrator cannot create a Domain Alias that the MX records don't already point to the SmarterMail box. A User Alias would be worthless since it will not look outside it's own domain. I guarantee you no User or Domain Administrator could NOT reproduce this problem on any of my servers. If there's some kind of API problem between SmarterMail and a control panel then that's a completely different issue.

Thanks, -Joe

Webio Replied

4/20/2015 at 9:49 PM

At the end users have no domain administrator privilages at all. They add domain in hosting control panel and they create mailboxes for them (created mailboxes have no possibility to enable domain administrator but API calls are being made using SmarterMail admin credentials). Sometimes domains are totally made up, sometimes domains are being registered in next few days and very often users are adding domains to configure hosting account for a domain which clients wants to move from other hosting company. User create mailboxes for his domain and use webmail function to migrate his emails from his previous hosting company to his new hosting company. So I don't think that there should be any issues with limiting adding domain by users and I don't see anything wrong that anyone can create whitehouse.gov or something else in his account because this is THEIRS account. My problem is that SmarterMail during Spool processing should deliver messages sent by other local users to proper MX server for whitehouse.gov from DNS configuration istead of making delivery for local domain just because it has higher priority. Don't you see anything wrong here?

How do you see scenario where you have 3k customers and for each of them you must create mail domain manually? This would be admin and support ticker nightmare.

Joe Wolf Replied

4/20/2015 at 10:08 PM

So this is a control panel problem, not SmarterMail as I suspected. The control panel is not checking the SmarterMail API for a proper response.

Thanks, -Joe

Webio Replied

4/20/2015 at 10:24 PM

Nope it is not. Users should be able to create whatever domains they want. Both URLs pointed by me in previous post are from discussion forums of hosting companies (discountasp and winhost). SmarterMail should not block creating any domain by its MX configuration because of scenario (and probably for a lot of other reasons) which I've presented (user is configuring his new hosting account for migration from previous hosting company).

Is SmarterMail is so great with blocking adding domains (I don't have other admins for SmarterMail so I didn't saw any block being made by smartermail during domain adding - is this somewhere documented?) then why there is option Reserved Domain Names then since SM should block adding new domain if its MX records don't point to it (once again I never saw any block attempt so )?

"System administrators can prevent certain domains names from being added to SmarterMail. For example, domains that are already used for free email services, like gmail.com or yahoo.com, are ideal additions to the reserve list as allowing administrators to add such domains to SmarterMail could affect message delivery. Similarly, domains that are traditionally reserved for testing and documentation, such as test.com or example.com are also ideal candidates for the reserve list."

Here is reason why Reserved Domain Names option exists:

I've checked SmarterMail documentation and there is only one place where "Verify MX record in DNS before add" is and it is Domain aliases. There is no verify MX record when adding main mail domain.

So when we have clarified that SM allows creating main mail domains where is no MX verification how do you see managing mail domains for 3k customers?

I'm wondering why you are not referring to main problem here: why messages are not being delivered for proper DNS records MX configuration? You are trying to tell me your view of managing mail domains which is ok but you are not referring at all to issue which I've reported. Big question here IMHO is why this has to be this way? Why SM can't just deliver messages to proper MX servers from domain DNS configuration? Why local domains are so important that their have higher priority than DNS configuration?

EDIT: I know that this is by design but why? Local deliveres are only a fraction of whole email deliveries so I don't see a reason why not use DNS query to send message to proper MX server for email message recipient domain.

Joe Wolf Replied

4/20/2015 at 10:39 PM

What you say is complete contrary to the administration of SmarterMail. Users nor Domain Administrators can create domains on SmarterMail. SmarterMail itself will not allow such activity. If your control panel allows that then you have a SEVERE problem with your control panel, not SmarterMail.

Let me make this perfectly clear: In SmarterMail a User cannot create a domain.

In SmarterMail a Domain Administrator cannot create a Domain Alias that does not have an MX record pointing to the SmarterMail service.

There is NO WAY to reproduce the OP's issue with SmarterMail. If your control panel allows it then your problem is with them, not SmarterTools.

The ONLY person that can create a Domain Alias without MX verification is the System Administrator. Not a User or Domain Administrator.

I use 5 different SMTP Server software. All work exactly the same way. They are authoritative for domains they host, then the Hosts file, then DNS. That's the industry standard.

If your control panel allows otherwise then it's a problem with the Control Panel creating Domains using Administrator privileges which is WRONG. The problem is in the control panel.

Do the testing yourself with SmarterMail. Log in manually (not Impersonate) and you will see that neither a User cannot create a domain at all, and a Domain Administrator cannot create a Domain Alias that doesn't already have an MX record pointed to your SmarterMail server. Give it a try and you'll see what I'm saying is the truth. If your control panel does it you have permissions set wrong or the control panel is not compatible with SmarterMail. TRY IT MANUALLY AND PROVE IT TO YOURSELF. If you can do it via the Control Panel, but not SmarterMail then you have your answer.

I'm NOT trying to be argumentative here, it's just that this is not a SmarterMail problem, but a control panel problem. You cannot create this problem with SmarterMail itself.

Thanks, -Joe

Webio Replied

4/20/2015 at 10:53 PM

I understand completely that user under SmarterMail can't create mail domain (because he is a user not admin).

But then why there is API and hosting control panel integration if mail domains should be created by mail server administrators? In scenario where SmarterMail is used for a company which is NOT a hosting company this is just fine. Evertyhing is managed by mail server administrator and he knows everything whats going on on his mail server(s) but once again I will ask: how do you see managing mail domains manually for 3k customers and more? Winhost and discountasp have them a lot more and as you see based on their forum replies to users asking about this issue they also allow users to manage their mail domains using control panel because it would be a nightmare and clients would move to other hosting companies when they would have to wait for their mail domain would be added manually by administrator.

Probably we will not understand each other but I hope Steve and Bruce (maybe someone else too?) back me up here.

Even if this is by design then I don't see any problem with discussing this design. You keep telling me that your point of view but have you wondered about why it works this way? I just don't see any advantages of having higher priority for local domains over DNS MX records configurations.

If you have changed thread to Not a problem then please to unmark it this way and change it to Discussion

Joe Wolf Replied

4/20/2015 at 11:05 PM

You asked, "I will ask: how do you see managing mail domains manually for 3k customers and more?" I so so for more than triple that number. Every domain added has to approved by a REAL ADMIN. In our case that ranges from a few seconds to a few minutes 24/7/365. You probably have your control panel mis-configured but I can't say for sure. Maybe there is a problem with the API, but I have disabled that entirely.

I will try and change it from NOT A PROBLEM, but in reality you should deal with your control panel company, not SmarterTools.

Thanks, -Joe

Joe Wolf Replied

4/20/2015 at 11:09 PM

I changed it to "Submitted". I suggest you open a ticked with your control panel provider first, then SmarterTools. I think you have a simple mis-configuration in your control panel. None of mine allow Admin access.

Thanks, -Joe

Webio Replied

4/20/2015 at 11:09 PM

Ok. Let's see what others will have to say here. If they will agree then I will have no problem with marking this topic as "not a problem" again but still I don't see why DNS records can't have higher priority.

Bruce Replied

4/21/2015 at 1:35 AM

I think this is a BIG problem.

We had a customer of one of our resellers once create a mail domain for gmail.com in the control panel, they did not add a catch all but meant for several hours until we caught this all emails from customers sent to @gamil.com address were rejected with a 550 user does not exist message.

Have now added gmail.com and a wide range of ISP's domains to the Reserved Domains List but this is not an ideal solution.

We host over 10,000 domains and customers can add domains through websitepanel control panel and create mailboxes for these domains which are added by websitepanel to smartermail through the smartermail API.

I think to have every customer having to contact support to enable mail for their domains when they add them to the control panel would be a support nightmare as we see dozens of domains added and removed everyday by customers.

Joe Wolf Replied

4/21/2015 at 5:58 PM

Thanks for the post, now I'm beginning to understand the problem. I know there is no way for any Domain Administrator or User to add a domain or cause this problem directly via SmarterMail. In your case WebsitePanel is creating the domains via the API. Since I don't use a control panel on our Windows Servers I can't test this and I don't use the API. I guess the solution would be for SmarterTools to create a new level of sub-Administrator for control panels that would require any new domain to match MX records (like the way a Domain Admin cannot add a Domain Alias that doesn't match the MX record).

Thanks, -Joe

Bruce Barnes Replied

4/21/2015 at 6:53 PM

Joe; I would have voted up your comment about not being able to add a domain that does not match an MX record, except you posted with a comment, and did not create a post to respond . . .

Webio Replied

4/21/2015 at 9:46 PM

IMHO this would be dead setting for hosting companies.

Scenario1: user wants to move his service but befoe he do that he wants to configure new hosting place for his services. He can't because SmarterMail will not allow him to create mailbox for his domain (and use Migrate function which will fetch all of his messages from current provider)

Scenario2: user is registering his domain and he wants to create just after registration his mailboxes. I'm not sure if he will have possibility because DNS queries will not work yet for just registered domain. I know that he can do this x minutes later but this could be annoying for end user.

Can someone please tell me why local delivery is so important? Like I said earlier local deliveries are only fraction of all deliveries so I don't believe in any response like "less DNS queries". I know that this is by design but what are advantages of this design?

Bruce Replied

4/22/2015 at 12:20 AM

I can not see the MX checking working either.

Many of our business customers who are transferring from another hosting company ask to setup mailboxes before they point their domain at our DNS servers so that while the new name servers are propagating they can still receive email.

It would be no good if a customer transferring from another provider has to wait up to 72 hours for the name servers to propagate before they can setup any mailboxes.

I think for businesses it would be unacceptable to them to not have email during the propagation from their previous provider for up to 72 hours.

Webio Replied

4/22/2015 at 10:03 PM

Hello,

any chance that someone from SmarterTools SmarterMail team could join discussion? Until now no one explained why this has to be this way other than "by design".

Thanks

Joe Wolf Replied

4/22/2015 at 10:44 PM

Just enter a Hosts file entry. Problem solved.

Thanks, -Joe

Webio Replied

4/22/2015 at 11:01 PM

I would say that this is more a hack than a solution and it requires manually adding host entry so again administrator has to do something where full automatisation is expected.

Bruce Barnes Replied

4/23/2015 at 1:32 AM

EDITED: to correct line breaks.

A couple of points:

1. It rarely takes 72 hours for a new domain to populate.

2. The biggest issue is security. Granted, I tend to be more intense on that topic than some other people, but security needs to come first.

3. Liability. Who's going to pay the legal bills when someone games a deep pocketed domain name owner's domain on a really large MX server, with tens of thousands of users hosted on it?

The long-term solution seems to be using DNS to see where a message should be routed, even when a domain name is built on an originating MX server.

Yes, it means more work, and less automation until the issue is resolved, but it's all about getting the message delivered to the valid location.

While there are probably some easy, short-term solutions, the IETF will probably have to weigh in on this one to develop a standard in lieu of the generally accepted practice of local delivery first, which is the currently "accept practice."

Merle Wait Replied

4/23/2015 at 5:19 AM

I don't agree with SM not being able to add a domain, unless the MX record points to it.

We use MX records priority like this:

MX 10 - Front-end gateway #1

MX 20 - Front-end gateway #2

MX 30 - BackUp gateway

MX 50 SMail

Gateways #1 and #2 move mail to SMail, after they have done their own filtering et al.

These gateways ... as it stands right now, DO NOT know anything specific about SM

other then that just happens to be the IP address that they move the email to, after filtering.

If you do an MX check in SM... it always says the MX does not point to it...

~~~~~

How do you get around that - the above rule was in place??

Webio Replied

4/23/2015 at 6:07 AM

Actually I have the same configuration. My domains MX servers don't contain main SmarterMail instance so all traffic is being routed by incoming and outgoing gateways so basically MX checking is useless here. I would love to have some kind of dropdown which allows selecting what have bigger priority - DNS MX servers configration or local domain if exists. Win win for everyone right?

Casey Neehouse Replied

3/16/2016 at 2:55 PM

This issue just cost me dearly. A customer chose to migrate their email from our server to gmail and did not disable the local domain or notify us to do so. As such, none of their site emails were being properly delivered due to the domain existing locally, and their site set to send messages through our server. They are now threatening litigation for hijacking their email. This is a major security and legal issue. Mail should obey DNS MX records. Please Correct.

Casey Neehouse Replied

3/16/2016 at 3:15 PM

I see that there is now a setting per domain to change how this is handled. This is still very frustrating.

Michael Muller Replied

8/23/2016 at 6:22 AM

I know this is an old thread, but this gets me all the time. A new customer is transferring their website to me, as well as their email. If I set up an email domain for them in SM any emails I send them go to that mailbox, not the one as specified in DNS. This is a big problem.

I have learned to not set up their email domain until I am ready to deal with it, but with the advent of APIs in the next version of SM (16), I will be writing in controls to use those hooks. Which means, whenever I create a new site using my management tool (creates DB, DSN, DNS, web folders, etc.) I will now be creating the email domain as well.

This issue MUST be resolved in version 16. Please.

--- Montague WebWorks Powered by RocketFusion

Michael Muller Replied

8/23/2016 at 6:24 AM

SM should use the same DNS that everyone else in the world uses. If set on a per-domain basis, the default should be DNS.

--- Montague WebWorks Powered by RocketFusion

Webio Replied

8/23/2016 at 6:47 AM

This has been fixed already but you must configure your SmarterMail correctly. Take a look here:

https://portal.smartertools.com/kb/a2995/mark-a-domain-as-hosted-externally.aspx

In my environment all domains (new and existing) are set to External MX with unchecked "Deliver locally if user exists". This way SmarterMail is delivering messages to correct MX servers instead of local delivery if domain already exists on SmarterMail instance.