Sto avendo difficoltà a passare da SendGrid ad Amazon SES.
Qualcuno potrebbe gentilmente condividere le proprie impostazioni da app.yml o confermare che le mie siano corrette?
## TODO: Il server SMTP utilizzato per validare i nuovi account e inviare notifiche
DISCOURSE_SMTP_ADDRESS: email-smtp.eu-west-2.amazonaws.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: xxxxxxx
DISCOURSE_SMTP_PASSWORD: "xxxxxxxxxx"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opzionale, valore predefinito true)
DISCOURSE_SMTP_AUTHENTICATION: login
Il dominio è verificato su SES, non è necessario il parametro di autenticazione SMTP.
Inoltre, potrebbe essere necessario rimuovere il tuo account SES dalla sandbox, se non è già stato fatto, e richiedere un aumento del limite. La condizione sandbox si applica per regione.
Sono ancora perplesso sul perché non vengano inviati email tramite AWS SES.
Quando invio un’email di test dalla pagina di amministrazione del nostro Discourse, viene semplicemente indicato ‘inviato’. Anche la richiesta di reimpostazione della password sembra procedere correttamente, ma l’email non arriva mai.
Non credo che SES registri i log, quindi non posso verificare se sta effettivamente ricevendo le email.
L’unica cosa che potrebbe causare problemi è che l’indirizzo reply-to utilizza un account gmail.com invece del dominio del nostro sito.
Qualcuno ha già incontrato questa combinazione/scenario in passato?
Questo è l’indirizzo email che apparirà nella riga “Da”. Deve essere un indirizzo nel dominio da cui SES invierà le email. SES non invierà email che fingono di provenire da Gmail. Non hai il controllo su gmail.com, quindi SES non invierà email con quel dominio nella riga “Da”. notification_email dovrebbe essere qualcosa@tuodominioverificato.
Stai dicendo che ciò che sto cercando di fare non è semplicemente possibile in SES a causa dell’indirizzo reply-to che appartiene al dominio gmail.com?
Anch’io utilizzo SES e funziona perfettamente per me. L’unica differenza che riesco a vedere rispetto alla tua configurazione è che la riga DISCOURSE_SMTP_AUTHENTICATION: login non è presente nella mia. Inoltre, ho entrambe le righe DISCOURSE_SMTP_ENABLE_START_TLS: true e DISCOURSE_SMTP_PORT: 587 commentate, anche se questo non dovrebbe fare alcuna differenza.
Le uniche tre righe che modifico nel file app.yml sono l’indirizzo SMTP, il nome utente e la password. Il resto rimane commentato così com’è in una installazione pulita, utilizzando i valori predefiniti. Dopo il rebuild, devo solo assicurarmi che l’impostazione del sito notification email sia impostata su un indirizzo che utilizza un dominio verificato su SES. Non uso più le virgolette per la password, ma nelle mie installazioni più vecchie le avevo inserite e funzionava comunque bene.
Sì, varrebbe la pena provare a modificare l’indirizzo “reply-to” utilizzando un indirizzo con il dominio SES verificato, come consigliato nella risposta precedente, solo per testare se questo risolve il problema dell’invio.
Se non funziona, controlla se il tuo host sta bloccando alcune porte e verifica nuovamente che le credenziali SES siano state generate correttamente. Vedo che hai confermato sopra che il tuo dominio è verificato su SES.
L’indirizzo di risposta è sullo stesso dominio dell’indirizzo mittente, sì, ma in alcuni casi non è lo stesso sottodominio (comunque lo stesso dominio principale). Entrambi i casi funzionano perfettamente per me.
Sono sicuro che tu l’abbia notato: hai verificato l’indirizzo email in uscita che Discourse utilizza per inviare? Se è notify@tuodominioverificato, devi andare in SES, nella seconda riga sotto
