1

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 [email protected] 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 [email protected]—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?

1
  • For option #1, you may consider using smtp-sink to perform backhole-mail-server
    – masegaloeh
    Apr 19, 2015 at 6:49

1 Answer 1

0

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.

4
  • 1
    Could you summarize the steps from the external link, in case it goes down?
    – Hyppy
    Apr 19, 2015 at 17:54
  • This solution would result in bounces being refused (at the TCP level), which is contrary to the advice I received in answer to What to do if one doesn't want to receive email bounces? If you think that is the correct approach, please post as an answer to that question. This question was predicated upon the assumption that it is necessary to receive bounces first and then discard them after receipt.
    – eggyal
    Apr 20, 2015 at 4:43
  • @Hyppy I don't want to specifically stress that particular guide. I just put it as a reference in case the OP didn't know much about what I was talking about. Luckily, it seems he/she does understand what a "send-only MTA" is, as that was the solution I was pushing towards, and not the guide itself. Apr 20, 2015 at 14:44
  • Eggyal, I realize what it does, and again, I know it is not the "correct" way, but I thought you were looking for alternative ways, different than those on your other thread. Receiving and dropping the bounces is the right way. For this question, I would go with Option #1 with smtp-sink, as @masegaloeh suggested. Apr 20, 2015 at 15:00

You must log in to answer this question.

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