-1

Some of our Linux servers are going to be moved out into a cloud. But the servers need to be able to email our users internally and are required to use our domain name as sender. The server cannot initiate data transfer into our network, i.e., the only way to send emails are through our mail server.
Unfortunately (but understandable) our security people don't allow external servers to send emails using our domain as sender so...
What I am thinking of doing is to setup a system where a server in-house initiate a connection through SSH, collect the emails and email them locally to our users because we are not allowed to have an open connection from the outside into our internal network which may be abused by hackers and it is not an option to add a relay server.
In the good old days (30 years back) we used (the technology called) UUCP (Unix-to-Unix-Copy) to transfer files, mails, news posting (NNTP), ... using modems :-) and I thought this setup would be useful again in a more secure way - but are the more modern alternatives/setup?

5
  • 2
    Just setup a VPN for your servers to allow to securely connect to your inhouse mail servers.
    – Sven
    Commented Jan 5, 2015 at 13:11
  • 5
    The Internet is a more modern alternative to UUCP. Just relay the email via a host which is authorized to send it. Commented Jan 5, 2015 at 13:12
  • 1
    @Sven I'm thinking his security people probably count a VPN as an open connection from the outside into their internal network.
    – Jenny D
    Commented Jan 5, 2015 at 13:48
  • @JennyD: My comment is older than the edit adding that particular limitation... In many cases, I also wouldn't accept that limitation for a VPN for such a special case, but I really like your fetchmail approach much better anyway :)
    – Sven
    Commented Jan 5, 2015 at 14:07
  • 1
    @Sven It's really a last resort kind of thing, the security staff should be competent enough to allow one of the more standard solutions... but as we all know, that's not always the case :-) (Also, I kind of liked UUCP back when I was in charge of the UUCP server at an ISP - though it's really past its prime by now!)
    – Jenny D
    Commented Jan 5, 2015 at 14:11

1 Answer 1

3

As I understand your problem, you have currently one or more incoming MX:es. When a server outside of your system connects to those MX:es, and the email it's trying to send contains either a From:-header, or an envelope sender, within your domain - then your MX server don't accept it.

UUCP is one way, yes, and I've actually seen it used over TCP/IP, but that was more than ten years ago if not more... But here are some alternative ways of resolving the issue, without having an open connection into your network (which I agree should be avoided).

  • Your MX:es can have whitelists of hosts that are allowed to use your domain name, and you can add your cloud servers to that whitelist. This presupposes that your cloud servers have fixed IP addresses.
  • If your cloud servers do not have fixed IPs, you set up a separate server which does, and you whitelist that one.
  • Your MX:es can have whitelists of email addresses within your domain that are allowed to be used from the outside, and you configure your cloud servers to use those specific addresses
  • If the MX:es only check the envelope sender, your cloud servers can use whatever envelope sender they like, but the From:-header in the email can still be one within your company domain
  • You set up a separate SMTP server which isn't on the MX list, and which allows incoming email traffic only from your cloud servers (either by IP whitelist or by authentication or both), and which can deliver to your internal email system. This server then needs to be in the same or similar DMZ/network segment/whatever as your existing MXes. You need to configure your cloud servers to use this one as a relay.
  • EDIT Your MX:s can allow incoming email with their own domains after authentication, and your cloud servers can be configured to authenticate themselves before sending.

All of these have the advantage that you can keep using regular SMTP without any non-standard workarounds. If your security department don't accept any of them, you could solve it with e.g. fetchmail from an internal server which will re-inject the emails from within your organization.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .