### Author:  [@ToddZ](https://meta.discourse.org/u/ToddZ)
#### Post date: [9월 25, 2023, 10:05오전 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/1 "2023-09-25T10:05:52Z")
음. @MathiasFoster와 @jryans와 동일한 Vultr 설정을 사용 중인데, 동일한 (Net::OpenTimeout) 문제를 겪었습니다. `ufw allow https`를 실행한 후 수신 이메일이 정상 작동하기 시작했습니다.
하지만 이제 사이트가 메일을 _보내지_ 못하고 있습니다. 수신 이메일을 설정하기 전에는 발신 이메일이 정상적으로 작동하고 있었습니다.
특별히 복잡한 설정은 없습니다:
notification\_email은 [admin@tasat.org입니다](mailto:admin@tasat.xn--org-db3mme233k).
발신 메일은 Hostinger의 smtp.titan.email을 사용합니다.
mail\_receiver.yml에는 다음과 같은 내용이 포함되어 있습니다:
```plaintext
`MAIL_DOMAIN` = forum.tasat.org
`DISCOURSE_MAIL_ENDPOINT` = https://forum.tasat.org/admin/email/handle_mail
`DISCOURSE_API_KEY` = [redacted]
```
스킵된 이메일(Skipped email)에서 `: Sender address rejected: not owned by user admin@tasat.org` 오류를 확인하고 있습니다.
이메일 시스템 설정에 익숙하지 않습니다. mail\_receiver.yml 문자열에서 `forum.`을 제거하고 "[replies@tasat.org](mailto:replies@tasat.org)"를 "[admin@tasat.org](mailto:admin@tasat.org)"의 발신 별칭(sending alias)으로 설정하는 것이 좋을까요..?
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [9월 25, 2023, 2:59오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/2 "2023-09-25T14:59:56Z")
메일 수신기는 Discourse와 이메일 발송과 독립적이며, 단순히 이메일 수신만하도록 구성된 간단한 이메일 서버 역할을 합니다. 이 수신기는 Discourse API를 사용하여 수신된 이메일을 Discourse로 전송합니다.
설정 과정에서 발송에 영향을 미칠 수 있는 유일한 요소는 `reply by email address`(이메일로 답장) 설정일 수 있습니다. 하지만 이 설정은 исходя 이메일의 `Reply-To` 헤더만 설정할 뿐, 발신자 주소에는 영향을 주지 않아야 합니다.
확인 차원에서 말씀하신 내용이 `app.yml`에 다음과 같이 설정되어 있는 것으로 보입니다:
```plaintext
DISCOURSE_SMTP_USER_NAME: admin@tasat.org
DISCOURSE_NOTIFICATION_EMAIL: admin@tasat.org
```
그리고 `reply by email address`에는 다음과 같이 설정되어 있습니다:
```plaintext
replies+%{reply_key}@forum.tasat.org
```
맞습니까?
그렇다면 답장이 허용되지 않는 이메일 알림은 정상적으로 작동합니까? 이메일 인증이 그 예시가 될 수 있으므로, 계정을 생성해 보시고 해당 이메일이 정상적으로 전송되는지 확인해 보실 수 있습니다.
이러한 구성에서 답장이 허용되는 이메일의 경우, 전송된 이메일은 다음과 같이 되어야 합니다:
`From: admin@tasat.org` (발신자 주소)
`Reply-To: replies+abc123@forum.tasat.org`
일반적으로 Reply-To는 발신자 정보의 일부로 취급되지 않으며, 사용자가 답장할 때 사용할 기본 수신자 주소를 제공하는 역할만 합니다. 하지만 Hostinger에서는 이를 발신자 정보로 취급할 수도 있습니다. `replies@forum.tasat.org`에 대해 발송용 별칭(alias)을 추가할 수 있을 것입니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9월 25, 2023, 5:03오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/3 "2023-09-25T17:03:26Z")
> [@ToddZ](#):
>
> 하지만 이제 사이트가 메일을 _보내지_ 않습니다. 수신 이메일을 설정하기 전에는 발신 이메일이 정상적으로 작동했습니다.
[https://www.mail-tester.com/에서](https://www.mail-tester.com/%EC%97%90%EC%84%9C) 받은 주소로 테스트 메일을 보내 보시면 어떻게 되나요?
`ufw allow https` 명령을 변경하는 것이 수신 메일에 영향을 미칠 수 있는 방법을 알 수 없습니다.
vultr이 25 포트로의 발신 연결을 허용하지 않는 것일 수 있습니다. 그러면 발신 메일이 작동하지 않는 현상을 설명할 수 있습니다.
발신과 수신 이메일은 대부분 서로 독립적입니다.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [9월 25, 2023, 11:29오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/4 "2023-09-25T23:29:44Z")
> [@pfaffman](#):
>
> `ufw allow https`를 변경하는 것이 수신 메일에 영향을 미칠 수 있다는 점을 이해할 수 없습니다.
Vultr(또는 ufw가 존재할 때 Docker를 설치하는 것)에는 컨테이너 간의 통신을 방지하는 규칙이 있어 메일 수신기가 Discourse에 연결할 수 없다고 생각합니다. `ufw allow https`는 이를 우회합니다.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [9월 26, 2023, 4:47오전 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/5 "2023-09-26T04:47:46Z")
하지만 Docker는 ufw를 우회하지 않나요?
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [9월 26, 2023, 3:08오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/6 "2023-09-26T15:08:16Z")
기본 네트워크에서는 컨테이너가 다른 컨테이너에 직접 연결될 때만, 즉 컨테이너 자체의 로컬 IP 주소를 사용할 때 해당 규칙이 적용됩니다.
메일 수신기가 사용자의 Discourse 도메인 이름을 조회할 때 해당 로컬 IP를 가져오지 못하므로, Docker 네트워크를 벗어나야 하며, Discourse에 도달하기 위해 최소 한 번은 ufw를 통과하게 됩니다.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [9월 26, 2023, 3:14오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/7 "2023-09-26T15:14:54Z")
제가 이 주제에 대해 생각하고 있었어요. 당신도 참여했던 주제입니다:
> [@UFW가 Discourse도 제한할까요?](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873):
>
> How can Discourse bypass UFW? I had enabled only port 22 so all other ports should be closed then. But a forum worked anyway. How’s that possible? DigitalOcean droplet, but that should not mean anything. And no one-click install, but official way. This is not a pure support question, but we don’t have here a catogory named Stupid basic questions by beginners wink
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [9월 26, 2023, 4:12오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/8 "2023-09-26T16:12:57Z")
이는 관련은 있지만 별개의 상황입니다. 외부에서 들어오는 연결에 대해 Docker가 노출된 포트를 통과시키기 위해 규칙을 추가하는 것입니다.
> [@supermathie](#):
>
> ```plaintext
> Chain DOCKER (2 references)
> pkts bytes target prot opt in out source destination
> 0 0 RETURN all -- docker0 any anywhere anywhere
> 0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443
> 107 6848 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:http to:172.17.0.2:80
>
> ```
저는 netfilter/iptables 체인 규칙에 대해 아주 익숙하지는 않지만, 위 내용은 다음과 같이 보여지는 것 같습니다:
1. 연결이 `docker0`, 즉 기본 Docker 네트워크에서 들어오는 경우, 이전 체인으로 반환됩니다(해당 체인의 규칙 처리를 중단).
2. 그렇지 않고 연결이 `docker0`를 제외한 곳에서 들어오는 경우, https 또는 http 프로토콜이라면 DNAT를 지정하여 FORWARD 체인으로 전달됩니다.
따라서 다른 주제에서 보여준 구성에서는 외부에서 https 또는 http 트래픽이 들어오면 Docker로 유도됩니다. 그러나 트래픽이 Docker 네트워크에서 온 경우, INPUT 체인으로 반환되어 거부되거나 드롭됩니다.
`ufw allow https`가 하는 일은 INPUT 체인에 이를 허용하는 규칙을 추가하는 것입니다. 이렇게 하면 위에서 설명한 대로 연결이 INPUT 체인으로 반환될 때 허용되어 Docker가 리스닝하는 것을 발견하고, 최종적으로 컨테이너로 라우팅됩니다.
---
### Author:  [@ToddZ](https://meta.discourse.org/u/ToddZ)
#### Post date: [9월 27, 2023, 1:00오전 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/9 "2023-09-27T01:00:40Z")
@Simon_Manning @pfaffman –
**수정: 메시지 끝 참고**
답변 주셔서 감사합니다! 잠시 자리를 비워 있어야 했지만, 이제 다시 이 문제를 파고들고 있습니다…
> [@Simon\_Manning](#):
>
> 확인차 말씀드리자면, `app.yml`에 아래 항목들이(그 외 다른 항목들과 함께) 포함되어 있는 것으로 보입니다:
>
> ```plaintext
> DISCOURSE_SMTP_USER_NAME: admin@tasat.org
> DISCOURSE_NOTIFICATION_EMAIL: admin@tasat.org
>
> ```
>
> 그리고 `reply by email address`에는 이렇습니다:
>
> ```plaintext
> replies+%{reply_key}@forum.tasat.org
>
> ```
>
> 맞습니까?
네, 현재 제 설정은 그렇습니다.
> [@Simon\_Manning](#):
>
> 그렇다면, 회신을 받지 않는 이메일 알림은 정상적으로 작동합니까? 이메일 인증이 그런 사례라고 생각되므로, 계정을 생성해 보시고 해당 이메일이 정상적으로 전송되는지 확인해 보실 수 있습니다.
지금 계정을 생성하려고 하면 제출 버튼이 아무 반응이 없습니다. 작동하지 않을 것 같다는 걸 알고 있는 것처럼요. (그리고 Skipped나 다른 곳에도 아무것도 표시되지 않습니다.)
> [@Simon\_Manning](#):
>
> 일반적으로 Reply-To는 발신자 정보의 일부로 취급되지 않으며, 사람들이 회신할 때 사용할 기본 To 주소를 제공하는 용도입니다. 하지만 Hostinger는 이를 그렇게 취급할 수도 있습니다. `replies@forum.tasat.org`에 대해 발신 별칭(sending alias)을 추가해 볼 수 있을 것입니다.
수정: [admin@tasat.org의](mailto:admin@tasat.xn--org-yh0o) 발신 별칭으로 "[replies@tasat.org](mailto:replies@tasat.org)"를 설정하고, 송신 및 수신 모두에서 작동하는지 확인했습니다. 또한 외부 클라이언트에서 `replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org`로 전송된 이메일의 전달도 확인했습니다.
_무언가_를 시도해 보기 위해 `reply by email address`를 변경했습니다:
`replies+%{reply_key}@forum.tasat.org`
에서
`replies+%{reply_key}@tasat.org`
로 변경했습니다.
하지만 결과는 변하지 않았습니다.
> [@](#):
>
> [https://www.mail-tester.com/](https://www.mail-tester.com/) 에서 가져온 주소로 테스트 이메일을 보내면 어떻게 됩니까?
mail-tester에 도착하지 않습니다. 모든 발신 시도는 다양한 메시지와 함께 “skipped” 아래에 기록됩니다:
```plaintext
553 5.7.1 :
Sender address rejected: not owned by user admin@tasat.org
```
아마 이것이 흥미로울 수도 있겠습니다..? discourse-doctor를 실행하면 발신 이메일이 다음과 같이 실패합니다:
```plaintext
==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Sending mail to REDACTED . .
Testing sending to admin@tasat.org using smtp.titan.email:587,
username:admin@tasat.org with plain auth.
SMTP server connection successful.
Sending to admin@tasat.org. . .
Mail was not sent.
Reason: 553 5.7.1 :
Sender address rejected: not owned by user admin@tasat.org
```
이메일 클라이언트에서 replies+ 주소(또는 [forum.tasat.org](http://forum.tasat.org) 주소)로 직접 보내면 작동합니다 – “replies” 별칭을 따르며 admin의 받은 편지함으로 도착합니다. 거절은 어디서 오는 것일까요?
"Prevent outgoing host email from interfering"라는 기사 섹션을 살펴봤습니다. /etc/postfix 경로는 없지만, 여기 제 netstat 출력입니다:
```plaintext
root@forum:/var/discourse# netstat -tulpn | grep :25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1487576/docker-prox
tcp6 0 0 :::25 :::* LISTEN 1487581/docker-prox
```
**중요한 수정 –** 오늘 밤 Titan 지원팀으로부터 회신을 받았습니다: _“Reply-to 주소와 From 주소가 동일해야 하며, 그렇지 않으면 이메일이 전송되지 않습니다.”_ 따라서 모든 문제 해결 시도는 물거품이 되고, 그 요구 사항을 강요하지 않는 새로운 이메일 호스트를 찾아야 할 것 같습니다.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [9월 27, 2023, 12:17오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/10 "2023-09-27T12:17:19Z")
> [@ToddZ](#):
>
> 그러니까 모든 문제 해결 시도는 무용지물이 되고, 그 요구 사항을 부과하지 않는 새로운 이메일 호스트를 찾아야 하는 것 같습니다.
이것은 포괄적인 목록은 아니지만, 설치 문서에는 전송 서비스 추천 목록과 Discourse에서 이를 사용하는 방법에 대한 기본 정보가 포함되어 있습니다: [discourse/docs/INSTALL-email.md at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/main/docs/INSTALL-email.md)
아래의 주제(해당 문서 하단에 링크되어 있음)에도 이 서비스 및 기타 서비스의 바운스 처리에 대한 정보가 있습니다:
> [@Configure VERP to handle bouncing e-mails](https://meta.discourse.org/t/configure-verp-to-handle-bouncing-e-mails/45343):
>
> Setting up bounces handling Discourse uses the [Variable envelope return path (VERP)](https://en.wikipedia.org/wiki/Variable_envelope_return_path) technique to handle bouncing e-mails. To enable VERP, set the “reply by email address” site setting with an email address template that uses the + sign. The default of replies+%{reply\_key}@discourse.example.com … works fine. If you are using your own or your company’s email server, then, that’s it tada Your discourse instance must be able to receive email sent to this address. This should work via POP, bu…
저는 Mailgun 플렉스 플랜(전부 무료 할당량 범위 내)을 사용하지만, 가격 체계에 대한 혼란이 있었고 제가 가입한 이후 신규 사용자를 위해 상황이 변경되었을 수 있다는 것을 알고 있습니다. 마지막으로 확인했을 때(아직 그런지 확실하지 않음)는 시험 기간이 끝난 후에도 플렉스 플랜으로 전환할 수 있었지만, 그 과정이 매우 불분명했습니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9월 27, 2023, 12:59오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/11 "2023-09-27T12:59:33Z")
> [@ToddZ](#):
>
> 그러면 문제 해결 과정은 전부 무용지물이겠고, 그 요구 사항을 부과하지 않는 새로운 이메일 호스트를 찾아야 할 것 같습니다.
맞습니다.
mailgun flex로 전환할 수는 있지만, 알아내기가 꽤 어렵게 되어 있습니다. 한 달에 한 번 정도는 왜 그렇게 찾기 어렵는지 그들에게 이메일로 문의하곤 합니다.
---
### Author:  [@ToddZ](https://meta.discourse.org/u/ToddZ)
#### Post date: [9월 30, 2023, 12:47오전 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/12 "2023-09-30T00:47:29Z")
@Simon_Manning & @pfaffman – 의견과 조언을 주셔서 다시 한번 감사드립니다. 덕분에 올바른 방향으로 나아갈 수 있었습니다.
현재 무료 플랜이 꽤 후해서 [MailerSend](https://www.mailersend.com/)를 사용해 보기로 했습니다. 우리 비영리 단체의 활동에 당분간 잘 맞을 것 같습니다. 지금까지는 잘 진행되고 있습니다 :grin:
---
### Author:  [@ToddZ](https://meta.discourse.org/u/ToddZ)
#### Post date: [3월 11, 2026, 2:37오후 UTC](https://meta.discourse.org/t/set-up-mail-receiver-but-now-site-wont-send-any-emails/283817/14 "2026-03-11T14:37:39Z")
이 주제는 마지막 답변 후 30일이 지나면 자동으로 닫힙니다. 새로운 답변은 더 이상 허용되지 않습니다.