드디어 동작하게 만들었습니다. 처음 원했던 방식은 아니지만, 제가 뭔가 잘못 읽은 것 같기도 합니다. 결론부터 말하면, Mailjet은 처음 시도(Mailjet)에서 바로 작동했습니다. 도움 주신 분들께 감사드리고, 해결책이 많은 좋은 포럼이라 다행입니다.
요약
긴 버전
어떻게 작동하게 만들었는지 설명드리겠습니다 (리눅스 지식이 거의 남아 있지 않은 사람이 이런 문제를 어떻게 해결하는지 보여드리고 싶어서요). 그래서 지루한 단계들도 모두 포함했습니다… 그 결과 개발자 팁 몇 가지와 가능한 버그가 하나 발견되었습니다.
Digital Ocean 스냅샷을 만들었습니다 (이전에 Discourse 업그레이드에서 좋지 않은 경험을 몇 번 했거든요 
→ 이번에는 30GB가 아니라 50GB가 있어서 최신 버전으로 업그레이드하는 것이 순조롭게 진행되었습니다. 어쨌든 고맙습니다)
작년 가을에 lfchosting이 hostpapa로 바뀌었기 때문에, 어차피 비용을 내고 있는 hostpapa를 사용하기로 결정했습니다.
lfchosting이 hostpapa로 이전하는 것에 대한 관련 없는 짧은 이야기. 외부에서 트래픽을 받아오는 제 통계 사이트 중 하나가 작동하지 않게 되었습니다. 지원팀에서는 3개월 동안 아무런 해결책이 없었습니다. THEN 누군가가 일부 방화벽 규칙을 비활성화할 것이라고 말했고 → 그 수정은 작동하지 않았습니다… 하지만 그 덕분에 힌트를 얻었습니다 → 그들은 이전 후에 ModSecurity를 설치해 두었고, 그 쓰레기를 버리자 모든 트래픽이 다시 잘 흘러들기 시작했습니다. 그저 말해두는데, 기존 고객을 이전하면서 새로운 방화벽/무언가를 사용하고, 고객은 트래픽 문제를 겪는데… 지원팀에서 누구도 아이디어가 전혀 없나요? 진짜로.
자격 증명이 정상인지 확인하려고 Outlook을 시도해 보았지만 작동하지 않았습니다 - 하지만 그것으로 너무 많은 것을 판단할 수는 없습니다. 실제로 처음에는 Pegasus Mail을 시도해 보았지만, 요즘은 그것도 별로 쓸모가 없습니다 - 다만 로그가 더 읽기 편하긴 합니다 .
telnet mail.papamail.net 465는 적어도 응답은 해 주었습니다 (여기서 바보라고 부르지 마세요)
머리를 쥐어짜며, 465는 starttls가 아니라 TLS/SSL을 의미하는 것 같은데… 끙끙.
아아, 그냥 app.yml을 변경하고 로그를 읽어서 테스트해 보겠습니다…
=>app.yml 편집 => smtp 비밀번호 난관
이중 인용부호를 붙일 것인가, 아닐 것인가? 이전에 작동했던 gmail 이메일 설정에는 이중 인용부호가 있었는데, 많은 게시물에서는 인용부호 없이 사용해야 하는 것처럼 보입니다. 음, discourse는 불필요한 인용부호를 제거할 만큼 똑똑할까요? 실제로 "password"를 비밀번호로 사용하는 사람은 꽤나 희귀할 것입니다 .
gmail이 기본적으로 비밀번호에서 이중 인용부호를 제거하기 때문에 이전에 gmail에서는 작동했던 것일지도 궁금해지기 시작합니다.
앱 재빌드 후, 테스트 이메일 전송이 작동하지 않습니다. 도대체 왜 그 로그를 테스트 페이지에서 바로 표시할 수 없는지 저는 이해할 수 없습니다 (힌트, 힌트 
, 음, 아마도 보안 위험일까요? ).
more shared/standalone/log/rails/production.log
필요한 것을 찾기에 별로 도움이 되지 않거나, 너무 많은 잡음이 있었습니다 (위에서 힌트, 힌트라고 한 부분을 참고하세요).
./discourse-doctor
별로 쓸모가 없었습니다.
./discourse-setup
정말 오래 걸립니다 (launcher의 app 재빌드와 비슷하게), app.yml을 변경하고 발신 이메일을 테스트하는 가장 빠른 방법이 무엇인지 궁금합니다?
discourse-setup 버그?: gjwha9T78&vv와 같은 비밀번호를 사용하면 app.yml에 이 손상된 줄이 생성되었습니다 (!):
DISCOURSE_SMTP_PASSWORD: "gjwha9T78 DISCOURSE_SMTP_PASSWORD: gjwha9T78&vv"
결국 이중 인용부호가 필요한 것이었습니다. 하지만 비밀번호에 "&"가 포함된 경우 discourse-setup이 app.yml에 "쓰레기"를 작성하는 것은 좀 나쁘다고 볼 수 있습니다.
n번째 앱 재빌드를 기다리는 동안… 혹시 모르니 mailjet을 설정해 두었습니다…
mailjet을 사용하여 한 번 더 재빌드하고, 이메일 전송이 바로 작동했습니다.
2시간 후의 결론 = mailjet이 작동합니다. 우후… 하지만…
app.yml 편집 + 재빌드보다 discourse에서 이메일 전송을 테스트하는 더 빠른 방법이 반드시 있을 것입니다.
제가 많은 일을 길고 힘든 방식으로 했다고 가정하고 있으므로, 누군가가 더 나은 방법을 지적해 줄 것이라고 확신합니다. 특히 여기서는 항상 능동적인 도움을 주지, “너 멍청한 아마추야”-스타일 은 아니니까요.
어쨌든 hostpapa도 실제로 작동하게 만드는 것에 꽤 집착하게 되었습니다. 어차피 제가 실제로 비용을 지불하는 것 중 하나이니까요. 제 추측이 맞다면 물론 여기에 게시하겠습니다. 다만 오늘 밤은 너무 늦었습니다.
이 문제를 해결하는 데 사용한 최고의 참고 자료:
유용한 자료 (25/465/587 포트 관련 사항을 이해하는 데):
Troubleshoot email on a new Discourse install
다른 이메일 제공업체를 시도할 준비가 되었을 때 유용한 자료:
https://github.com/discourse/discourse/blob/main/docs/INSTALL-email.md
