Controllo retroattivo della Mailgun api key (nessuna API key dovrebbe essere richiesta se i bounce sono gestiti dal mail receiver)

Bug
1

Ho notato che molti siti si lamentano del fatto che non è definita alcuna chiave API di Mailgun, ma (almeno la maggior parte di) quei siti ricevono risposte tramite il container mail-receiver e gestisce quei bounce, quindi la chiave API (e il webhook corrispondente su Mailgun) non devono essere richiesti. Sembra che la logica nelle specifiche (e quindi nel codice) sia invertita:

La missing_mailgun_api_key_spec

Mostra questo:

    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

si lamenta se abbiamo le risposte abilitate, ma in quel caso non abbiamo bisogno del webhook e

    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

Qui NON stiamo elaborando i bounce con il mail receiver e siamo tranquilli al riguardo.

Sono confuso o è al contrario?

Beh, forse sono confuso. Sembra proprio che il mail receiver non stia informando Discourse dei bounce. Un sito trafficato non ha messaggi di bounce recenti.

Ma:

E:

Quindi questa documentazione suggerisce che se hai un mail receiver funzionante dovrebbe gestirlo. E il codice che una volta ho scritto in alcuni dei miei strumenti interni che impostavano questi webhook dice “# non servono webhook quando abbiamo un mail receiver”

3 Mi Piace