The problem of your (our) external mail gateway using internal DNS views

March 25, 2020

Suppose, not hypothetically, that you have an external mail gateway (your external MX, where incoming email from the Internet is handed to you). This external MX server is a standard server and so you install it through your standard install process. As part of that standard install, it gets your normal /etc/resolv.conf, which points it to your local DNS resolvers. If you have a split horizon DNS setup, your local, internal DNS resolvers will naturally provide the internal view, complete with internal only hosts and entire zones for purely internal 'sandbox' networks (in our case all under a .sandbox DNS namespace).

Now you have a potential problem. If you do nothing special with your external MX, it will accept SMTP envelope sender addresses (ie MAIL FROM addresses) that exist only in your internal DNS zones. After all, as far as it is concerned they resolve as perfectly good DNS names with A records, and that's good enough to declare that the host exists and the mail should be accepted. You might think that no one would actually send email with such an envelope sender, and this is partially correct. People in the outside world are extremely unlikely to do this. However, people setting up internal hosts and configuring mailers in straightforward ways are extremely likely to send email to your external MX, because that's where your domain's MX points. If their internal machine is trying to send email to 'owner@your.domain', by default it will go through your external MX.

(If the email is handled purely locally and doesn't bounce, things may go okay. If someone tries to forward their email to elsewhere, it's probably not going to work.)

Fortunately it turns out that I already thought of this long ago (possibly after an incident); the Exim configuration on our external MX specifically rejects *.sandbox as an envelope sender address. This still lets through internal only names that exist in our regular public domains, and there are some of those. This is probably not important enough to try to fix.

Fixing this in general is not straightforward and simple, because you probably don't already have a DNS resolver that provides an external view of the world (since you don't normally need such a thing). If I had to come up with a general fix, I would probably set up a local resolving DNS server on the external mail gateway (likely using Unbound) and have that provide a public DNS view instead of the internal one. Of course this might have side effects if used on a system wide level, which is probably the only way to really do it.


Comments on this page:

Given an external gateway set up with only a public DNS view, could you not also use your internal DNS to return your internal mail server to local machines when they ask for your MX? If so, they could successfully send such mail, instead of having it rejected, without at the same time giving external senders the opportunity to do the same – no? Would this actually be desirable in practice?

By cks at 2020-04-06 23:21:29:

Even our internal mail server doesn't accept SMTP envelope sender addresses that are in our special .sandbox internal zone. It's simply too hard to make sure that they never, ever leak out into the outside world, since people forward their email and want to notify external email addresses about problems with (or on) their machines and so on.

(Generally the outside world is going to immediately reject them, and often our attempts to deliver a bounce somewhere will stall and eventually time out.)

Written on 25 March 2020.
« How we set up our ZFS filesystem hierarchy in our ZFS pools
Any KVM over IP systems need to be on secure networks »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Mar 25 00:40:16 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.