Originating (non-critical) emails from a "less-trusted" host

Question

Background

We have a webapp running on webapp.example.com that (amongst other things) sends messages by email from time to time. These messages are non-critical: whilst we would like to make a best effort at delivering them, knowledge that message delivery failed is of no interest.

With this in mind, yesterday I asked What to do if one doesn't want to receive email bounces?—regrettably it seems the answer is to discard such bounces after first receiving them (rather than refusing them, e.g. at the SMTP layer or lower; or transmitting the original messages with a null return-path).

The options

Suppose that the messages generated by the webapp currently have a return-path of webservice@webapp.example.com and, in the DNS, the domain example.com. is fully defined by the following records:

@        SOA    ns.example.net. hostmaster 1 86400 7200 604800 300
         NS     ns.example.net.
         NS     ns.example.org.

         MX 1   mx.example.net.
         TXT    "v=spf1 a:192.0.2.0/24 -all"

webapp   A      198.51.100.1
         TXT    "v=spf1 a -all"

Our problem is that, in order to receive bounce messages (albeit purely so that they can then be discarded), we think that either:

1. webapp.example.com must run an SMTP server that accepts the bounce messages;

2. some other machine must run an SMTP server that accepts the bounce messages, and an MX record must be added to webapp.example.com. so that they are delivered there; or

3. the return-path must be changed, e.g. to webapp@example.com—in which case not only must that domain's mail exchangers accept the bounce messages but, also, either:

   (a) the sender policy for the resulting domain, e.g. example.com., must be updated to include a:webapp.example.com; or

   (b) the webapp must relay all outgoing messages through hosts approved by that domain's sender policy, e.g. 192.0.2.0/24.

The problems

Option #1 is undesirable because we don't especially want the additional security exposure of running an additional public-facing service on the machine that hosts the webapp (least of all one that accomplishes so little).

Option #2 is undesirable because our only public-facing mailservice is provided by a third party, and creating new recipient domains is outside the scope of our existing service agreement.

Option #3(a) is undesirable because we do not wish to grant webapp.example.com permission to originate messages from other senders within example.com.

Option #3(b) is undesirable because it would entail maintaining a VPN connection from the (public-facing) webapp.example.com to our secure, internal-only network.

So what should we do?

Perhaps option #2 would be the best solution in many cases. However, in light of the reasons given above, for us option #1 looks the least bad—yet it still feels like tremendous overkill. Is there a better way?

Answer 1

By reading your previous question thread, I gather that you are using exim. My suggestion then would be to configure it as a "send-only" MTA. I've personally used this guide to quickly configure send-only mail servers on public networks. Basically what it does is refuse external connections to the smtp port.

I know it is not the most "standard" way of resolving the issue, but it is very practical.

The downside is that some email providers may not like that the originating server can not be reached back, and refused to accept mails from it altogether. In my experience, I have never seen such thing happening, but I guess it depends on the amount of 'non-critical' mail that you are sending, and how often do those mails get bounced.