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:
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”
Mi sono appena imbattuto anche io in questo. Se hai abilitato il ricevitore di posta, questo avviso non ha senso. Ho semplicemente ignorato l’avviso dato quello che ho letto qui (grazie Jay!), ma non posso fare a meno di pensare che questo potrebbe essere gestito meglio. Almeno fornisci un link all’impostazione in modo da non doverla cercare (spoiler: non è nelle impostazioni email), e sull’impostazione fornisci una descrizione migliore con maggiori dettagli e magari un link a un argomento di documentazione su meta?
Mentre indagavo su questo, ho notato che avevamo un controllo dei problemi solo per Mailgun. Quindi ho fatto un po’ di refactoring per aggiungere un controllo dei problemi globale per la “gestione dei rimbalzi delle email” che funzionerà per tutti i provider di posta che abbiamo configurato.