Também estou vendo isso, o que notei como problemático quando spam falso recentemente usou o endereço de resposta (replies+abc123@instance) para From, acionando o Discourse a criar uma série de respostas automáticas para si mesmo.
Pelo que pude apurar, toda a funcionalidade de rejeição rápida foi mesclada e o readme do mail-receiver fala sobre o uso de BLACKLISTED_SENDER_DOMAINS, que faz parte da rejeição rápida, no entanto, a rejeição rápida está desativada por padrão.
A alteração acima nunca foi mesclada, citando a necessidade de investigar a compatibilidade com versões anteriores e, na ausência de DISCOURSE_BASE_URL, a rejeição rápida é desativada pela seguinte linha.
O aplicativo mail receiver é escrito de forma que lida com DISCOURSE_BASE_URL ou DISCOURSE_MAIL_ENDPOINT, como mostrado abaixo, e o readme não menciona o último, então acho que seria seguro aplicar a alteração do esse pull request, usando https em vez de http para refletir uma alteração mais recente na amostra.
A alteração proposta pelo pull request significará que a rejeição rápida estará habilitada por padrão para novos operadores do mail-receiver, ou seja, operadores que copiam a amostra como ponto de partida.
Operadores existentes continuarão com ela desativada até que o yml seja manualmente atualizado para usar DISCOURSE_BASE_URL. Se minhas afirmações aqui forem precisas, talvez algo sobre isso deva ser postado em #feature:announcements após a atualização da amostra.
Também seria simples fazer algo muito semelhante ao endpoint handle_mail para o endpoint de rejeição rápida, ou seja, inferir o endpoint de DISCOURSE_MAIL_ENDPOINT se DISCOURSE_BASE_URL não existir.
A rejeição rápida poderá então ser habilitada por padrão para operadores novos e existentes. Ficarei feliz em fazer um pull request para essa alteração se habilitá-la para todos (que reconstruam o mail-receiver após a alteração) for desejável.