Personal i don’t use anymore, but yes for me that was the reason
Yes I chose it because it was recommended and it sent the most email for free out of the recommended services. After discovering there is no clear way for EE to communicate bounce info to Discourse, I plan on making the switch to Mailgun.
EE should be removed from the recommended services IMO due to it not fully integrating with Discourse like the others do. Or at the very least a disclaimer should be added next to the recommendation.
Ran into this same issue over last two months and now regretting using Elastic Email without knowing this limitation.
Just created a pull request for this:
https://github.com/discourse/discourse/pull/6459
Looks like their pricing also changed completely
100/day limit
Just created a PR to remove it completely as it lost the only benefit it had:
https://github.com/discourse/discourse/pull/6994
Their paid plans aren’t widely out of line with the others listed. Those suggestions aren’t only for small communities interested in a free ride.
Would recommend updating their details to reflect the change, rather than unilaterally deciding to remove them completely.
(as mentioned on GitHub)
I understand, however as mentioned in the for-removal section and in this thread, the main issue with elastic is the double-footer (which also causes re-subscribe issues); as such I don’t think it should be considered as a recommendation (unless that issue changes).
I believe that the main reason it was kept on the list is that of the generous free plan; given the multiple integration issues.
I’ve filed an alternate PR with the amendments I suggested. Unless @codinghorror asks it be removed all we need to do is update it as-is.
Based on the new severe restrictions to the free tier, Elastic is now sorted at the bottom in the docs, whereas it used to be at the 
so this issue should naturally resolve itself over time.
월 6,000통까지 무료 이메일을 제공하는 Mailjet도 있습니다.
저는 비영리 파트너십을 가지고 있는 Elastic Email에 관심이 있었습니다. 제가 비영리 단체를 위한 포럼을 운영하고 있기 때문이죠.
구독 해지 링크와 관련된 문제가 정확히 무엇인지 여전히 명확하지 않습니다. 사용자가 Discourse가 추가하는 링크 대신 해당 링크를 클릭했을 때(또는 가입 확인 이메일처럼 Discourse 링크가 없는 경우) 정확히 어떤 일이 발생하는지 요약해 주실 수 있나요?
업데이트: Elastic Email은 이제 Discourse 관리자와 협력하여 EE 구독 해제 링크를 비활성화하고, Discourse를 통해 구독을 관리할 수 있습니다.
저는 이 문제를 그들의 지원팀에 제기했고, 다음과 같은 답변을 받았습니다:
안녕하세요, Dan님.
저희 고객 중 일부는 discourse.org를 사용하고 있으며, 그들의 전송 통계에 대해 매우 만족하고 있습니다. 다시 말해, 그들은 모두 저희가 기꺼이 서비스를 제공하는 정당한 기업들입니다.
귀하의 상황을 고려하여, 귀하와 협력하여 구독 해제 링크를 비활성화하겠습니다. 이렇게 하면 Discourse.org를 통해 구독을 관리할 수 있게 됩니다.
귀하에게 도움이 되기를 바랍니다.
감사합니다
Lubomir
Dan, 문제는 단절이 발생한다고 생각합니다. Discourse의 데이터는 이메일이 더 이상 전송되지 않는다는 사실을 반영하지 못하며, 이메일 서비스의 억제 목록(suppression list)에 갇히게 됩니다.
그 결과, Discourse에서 이를 주기적으로 수동으로 정리해야 하는 번거로운 작업이 생깁니다.
또한, 아마도 더 큰 문제는 사용자가 Discourse 인터페이스를 통해 구독을 단순히 다시 활성화할 수 없고, 이메일 서비스에서 억제를 해제하는 방법을 알아야 한다는 점입니다.
정말 좋은 소식입니다! 감사합니다. 후속 조치를 취하겠습니다.
위에서 설명한 것과 같은 문제입니다. 제 생각에는 Mailjet이 이러한 상황이 발생했을 때 Discourse에 알릴 수 있도록 Mailjet용 웹훅을 추가해야 합니다. (Mailgun 등에 대한 #howto가 있습니다.)
다만 Mailjet이 해지 링크를 제거하는 것은 좋지만, 주소가 다른 이유로 작동하지 않게 되는 경우는 여전히 커버되지 않습니다.
최근 Postmark를 위한 PR을 추가했습니다: Postmark bounce support? - #6 by pfaffman.
제 판단은 아니지만, ElasticEmail에 대한 유사한 PR도 환영받을 것이라고 생각합니다.
그들의 웹훅은 여기에서 문서화되어 있습니다: https://help.elasticemail.com/en/articles/2376855-how-to-manage-http-web-notifications-webhooks
방금 그들과 통화했는데, 내 이메일에서도 해당 링크를 제거할 의향이 있다고 밝혔습니다.
정말 좋습니다!
다만, 그들이 도움을 주는 기준 중 하나는 모든 이메일이 Discourse를 통해 생성되어야 한다는 것인 것 같습니다. (
)