Comprobación de api key de Mailgun al revés (no se requiere API key si el receptor de correo maneja rebotes)

He notado que varios sitios se quejan de que no hay ninguna clave API de Mailgun definida, pero (al menos la mayoría de) esos sitios reciben respuestas a través del contenedor de recepción de correo y este maneja esos rebotes, por lo que la clave API (y la webhook correspondiente en Mailgun) no necesitan ser obligatorias. Parece que la lógica en las especificaciones (y, por lo tanto, en el código) está invertida:

La missing_mailgun_api_key_spec

Muestra esto:

    context "when using Mailgun without an API key" do
      let(:replies_enabled) { true }
      let(:mailgun_address) { "smtp.mailgun.org" }
      let(:api_key) { nil }

      it do
        expect(check).to have_a_problem.with_priority("low").with_message(
          "The server is configured to send emails via Mailgun but you haven't provided an API key used to verify the webhook messages.",
        )
      end

Se queja si tenemos las respuestas habilitadas, pero en ese caso, no necesitamos la webhook y

    context "when replies are disabled" do
      let(:replies_enabled) { false }
      let(:mailgun_address) { anything }
      let(:api_key) { anything }

      it { expect(check).to be_chill_about_it }
    end

Aquí NO estamos procesando rebotes con el receptor de correo y estamos tranquilos al respecto.

¿Estoy confundido o esto está al revés?

Bueno, tal vez estoy confundido. Parece que el receptor de correo no le está informando a Discourse sobre los rebotes. Un sitio concurrido no tiene mensajes de rebote recientes.

Pero:

Y:

Por lo tanto, esta documentación sugiere que si tienes un receptor de correo que funciona, debería estar manejando esto. Y el código que una vez escribí en algunas de mis herramientas internas que configuraban estas webhooks dice “# no necesitamos webhooks cuando tenemos un receptor de correo”.

3 Me gusta