Ma ci sono anche alcuni problemi con Elastic Email Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail - #8 by pfaffman
Jay, grazie per averlo sollevato. Fammi capire meglio:
Ciò a cui stai attirando l’attenzione è: quando le persone ricevono email da Elastic Email, viene loro fornito un link molto evidente e possono disiscriversi unilateralmente dalla ricezione delle email, e Discourse non ne verrà a conoscenza? Tu, in qualità di SA, rimarrai all’oscuro?
Non ho esperienza diretta.
Sembra che inseriscano un link per la cancellazione e che sia necessaria un’intestazione speciale per farla scomparire. Non so se esista un modo per utilizzare Elastic Email con un webhook che notifichi a Discourse le cancellazioni, ma non sono elencati in Configure VERP to handle bouncing e-mails.
Penso che, se riesci a far funzionare AWS, sia probabilmente la soluzione migliore, ma non è una buona soluzione per chi viene qui per imparare a configurare l’email.
Mailgun è davvero semplice.
Grazie.
Per me è una questione ormai irrilevante, e ve lo spiego: SparkPost ha fatto esattamente la stessa cosa, anche se ammetto di non aver mai controllato se esistessero dei hook che avrei potuto utilizzare (che sciocco, perché ce ne sono ed è il 2019 FGS).
In quel caso, ne sono venuto a conoscenza solo perché il sito interessato serve la mia comunità locale; ho così incrociato l’utente che aveva cliccato per sbaglio sul link di disiscrizione nella mail inviata da SparkPost e si lamentava di non ricevere più le email di reset della password. SparkPost dispone comunque di un registro di controllo per questo e della possibilità per gli amministratori di riabbonare qualcuno (ovviamente da usare con parsimonia!), quindi una volta scoperta la questione è stato facile risolvere. La prossima volta saprò configurare meglio la mia email.
Mi state però spingendo verso Mailgun, grazie!
Vorrei davvero che ci fosse un modo più “generico” per gestire i rimbalzi delle email tramite webhook in Discourse. Il nostro provider preferito (Postmark) non è nella lista, il che significa che continuiamo a inviare email a indirizzi che hanno subito un rimbalzo.
Sarebbe fantastico avere un qualche tipo di parser magico e generico per i webhook JSON in arrivo relativi ai rimbalzi delle email!
Ciò che intendi è che sarebbe fantastico avere uno “standard magico per i webhook JSON”. Al momento, ogni servizio di posta ne crea uno proprio, quindi è necessario un parser webhook separato. Creare un plugin che lo faccia non sarebbe così difficile e potrebbe essere disponibile nel Marketplace (e potrebbe essere accettato come PR) per una cifra dell’ordine di 500 $.
Sì, stavo proprio pensando che, assumendo che oltre il 90% dei dati di rimbalzo in arrivo siano in formato JSON o in un altro formato analizzabile con espressioni regolari, potrebbe essere possibile indicare tramite un’impostazione il “campo” JSON che rappresenta l’indirizzo email rimbalzata e, eventualmente, un altro campo che rappresenta il tipo di rimbalzo (hard, soft, ecc.).
Potrebbe essere elencato come un “parser generico regex per webhook di email di rimbalzo in arrivo”. Il nome scorre bene 
Potrebbe aiutare a gestire il continuo turnover che probabilmente continueremo a vedere per questo tipo di servizio.
Siamo un sito intranet aziendale a basso volume, quindi per ora probabilmente ci accontenteremo di così.
Da un’altra discussione, puoi anche far scomparire il link di disiscrizione extra di ElasticMail indicando loro dove si trova quello di Discourse: annotandolo in modo speciale come {unsubscribe:{https://.....}} (ti consiglio di confermare con l’assistenza prima di inviare una pull request).
Questo potrebbe probabilmente essere realizzato modificando le traduzioni?
Anche io stavo usando SparkPost per le mie istanze di Discourse e di recente ho ricevuto questa notifica da SparkPost.
Quindi ho cercato un’alternativa.
Ho configurato SendGrid e sembra funzionare bene finora. Sto usando il piano Basic per 15$/mese.