I am also seeing this, which I noticed as being problematic when bogus spam recently used the reply to address (replies+abc123@instance) for From, triggering Discourse to create a series of automatic responses to itself.
From what I can tell, all of the fast rejection functionality was merged and the readme for mail-receiver talks about using BLACKLISTED_SENDER_DOMAINS which is part of fast rejection, however fast rejection is disabled by default.
https://github.com/discourse/discourse_docker/pull/344/files
The above change was never merged, citing a need to investigate backwards compatibility and with the absence of DISCOURSE_BASE_URL, fast rejection is disabled by the following line.
The mail receiver app is written such that it handles either DISCOURSE_BASE_URL or DISCOURSE_MAIL_ENDPOINT as shown below and the readme doesn’t mention the latter, so I think it would be safe to apply the change from that pull request, using https rather than http to reflect a more recent change to the sample.
The change as proposed by the pull request will mean that fast rejection is enabled by default for new operators of mail-receiver, that is operators who copy the sample as a starting point.
Existing operators will continue to have it disabled until the yml is manually updated to use DISCOURSE_BASE_URL. If my assertions here are accurate, perhaps something about this should be posted to #feature:announcements after the sample is updated.
It would also be straightforward to do something very similar to the handle_mail endpoint for the fast rejection endpoint, that is infer the endpoint from DISCOURSE_MAIL_ENDPOINT if DISCOURSE_BASE_URL doesn’t exist.
Fast rejection can then be enabled by default for both new and existing operators. I would be happy to make a pull request for this change if enabling it for everyone (who rebuilds mail-receiver after the change) is desirable.