여기서 새로운 기능 요청을 올립니다. 현재 Discourse는 단일 이메일 주소만 허용하며, 이 주소는 envelope-from과 reply-to 모두에 사용됩니다. 만약 사이트가 이메일 전송에는 자체 도메인의 SMTP를 사용하되, 이메일 답장은 다른 도메인(예: gmail)으로 보내기를 원한다면, 전송된 이메일은 DMARC 검사를 통과하지 못하게 됩니다. 이 두 헤더 필드를 분리하면 DMARC 실패를 방지할 수 있으며, 동시에 반송된 이메일(bounced emails)을 처리하는 기능도 유지할 수 있습니다.
이 주제에 대한 자세한 내용은 아래를 참조하세요.
이 시나리오에서 바운스(bounce)가 어떻게 처리되는지 잘 이해가 되지 않습니다. 바운스는 Reply-To 헤더의 주소가 아니라 envelope from 주소로 전송됩니다. 따라서 envelope from이 VERP 태그가 붙은 이메일을 처리할 수 없다면, 여전히 문제가 생길 것입니다.
참고하신 주제에서 From: 헤더의 도메인에 대한 DKIM 서명이 왜 작동하지 않는지에 대해 설명하지 않으셨습니다. SPF가 실패하더라도 DKIM 서명은 DMARC 정렬을 제공해야 합니다. 제 위치라면 이 방법을 채택할 것입니다. (아니면 yyy.com 수신 SMTP 서버 관리자에게 포크를 들고 찾아가는 방법도 있겠네요. 어떤 종류의 MTA가 상세 주소 지정(detail addressing)을 전혀 지원하지 않는 것일까요?!?)
MTA가 catch-all(모든 메일 포착)을 지원하기 때문에 작동할 것입니다. VERP를 지원하지는 않지만, 지정되지 않은 모든 이메일을 특정 이메일로 전달하도록 구성할 수 있으므로 바운스(반송) 응답이 유실되지 않습니다.
또한, envelope-from과 reply-to를 분리하면 envelope-from에는 VERP 주소를 포함할 필요가 없습니다. _discourse@yyy.com_과 같은 단순한 주소면 충분합니다. 따라서 바운스되어 돌아올 때 _discourse@yyy.com_으로 반환되며, SPF가 실패하지 않습니다.
reply-to에는 _discourse-yyy+sdfkj33@gmail.com_과 같이 VERP를 지원하는 다른 이메일을 사용할 수 있습니다. 메일이 성공적으로 전달된 후 사용자가 답장하면, VERP를 지원하는 Gmail 서버로 전송되어 DMARC 실패가 발생하지 않습니다. from 헤더가 여전히 _yyy.com_이기 때문입니다.
동의합니다. 하지만 우리는 MTA를 만들지 않으니까요. catch-all 주소 지정을 지원하기 때문에 VERP를 지원하지 않습니다. 안타깝게도 상황이 이런 식입니다. Discourse가 작은 조정으로 더 다양한 생태계를 지원할 수 있기를 희망합니다. Gmail을 사용하여 답장을 처리하는 많은 소형 사이트들이 이런 상황에 처해 있을 것입니다.
MTA가 catch-all을 지원한다면, 왜 동일한 기능을 사용하여 응답을 전달하지 않고 gmail을 완전히 제거하지 않는 것인가요?
envelope from은 VERP를 반드시 지원해야 하는 주소입니다. 바운스의 원인을 신뢰할 수 있게 식별하는 유일한 방법은 원래 이메일의 envelope from 주소에 포함된 정보를 사용하는 것이기 때문입니다. Michael이 이전에 설명한 바와 같이 말입니다.
그 주장에 대해서는 의문이 듭니다. gmail 주소를 응답에 사용하는 것은 어색하고(janky), 항상 어색했습니다. mail-receiver는 응답(및 바운스)을 처리하는 훨씬 더 직관적이고 신뢰할 수 있으며 어색함이 적은 방법입니다.
gmail을 사용하는 그 작은 사이트들 중에서도 정말 작은 사이트들은 아마도 ToS(이용약관)를 무시하고 gmail을 발신 릴레이에도 사용하고 있을 것이며, 나머지 대부분은 상세 주소 지정(detail addressing)을 지원하지 않는 MTA에 종속되어 있지 않을 가능성이 높습니다.
도메인 전체를 대상으로 하는 catch-all이기 때문에, discourse에 사용되는 이메일 주소는 하나뿐입니다.
반드시 그런 것은 아닙니다. 저는 현재 VERP 없이 사용하고 있으며 정상적으로 작동하고 있습니다. 제 문제는 discourse가 envelope-from과 reply-to 주소를 설정하는 방식 때문에, SPF/DMARC 실패 없이 사용자가 gmail로 직접 회신할 수 없다는 것입니다. 대신 MTA가 gmail로 전달하도록 설정해야 합니다. 만약 DMARC/SPF 실패 없이 gmail로 직접 회신할 수 있다면, 응답 보안을 위해 VERP를 사용할 수 있을 것입니다. 물론 반송된 이메일(bounced email)의 경우 VERP는 무시되겠지만, 현재 구현 방식보다 여전히 더 안전합니다.
그것은 여기에서 설명했듯이 선택지가 아닙니다. gmail은 수신(inbound)에만 실용적으로 사용할 수 있습니다. 호스팅 제공업체로부터 이미 MX를 가지고 있는 상태에서 직접 수신용 MX를 설정하는 것은 초보자에게는 도전적일 수 있습니다. gmail로 직접 회신하는 것이 훨씬 쉽고 오류 가능성이 적습니다.
아마도 제 생각의 흐름에서 놓치고 있는 부분이 있을 수 있습니다. envelope-from과 reply-to 주소를 분리하는 것에는 장점만 보이며, 더 다양한 생태계를 지원하고 SPF/MARC 실패를 피하는 데 도움이 되면서 더 안전합니다.
제 생각에는 지금까지 말씀하신 문제의 정답은 DKIM을 설정하는 것입니다. IMO, 사용 사례를 고려할 때 메일 구성을 더 복잡하게 만들고 오류가 발생하기 쉬운 상태로 만드는 것은 정당화되지 않습니다.
DKIM은 이미 설정되어 있으며, 문제는 SPF가 실패하는 것입니다.
envelope-from와 reply-to 주소를 분리하기 위해 추가 필드를 도입하면 유연성이 크게 향상되고, SPF 통과도 가능해집니다 (SMTP 서버가 이메일을 전달하거나 VERP를 지원하지 않는 경우 SPF는 통과하지 못합니다). 이 필드는 UI에서 숨기거나, 관리자가 명시적으로 오버라이드하지 않는 한 기본적으로 envelope-from과 reply-to 주소가 일치하도록 설정할 수 있습니다. 설명에는 이 페이지를 참조하도록 안내할 수 있습니다. 그러나 이것이 상황을 더 악화시킬 수 있는 방법은 보이지 않으며, 오히려 개선될 수밖에 없습니다 — 두 주소가 동일한 경우(이 경우 여기에서 설명된 모든 시나리오에서 SPF가 실패합니다)이거나, 그렇지 않으면 전달률이 향상되기 때문입니다.