Открываю здесь новую заявку на добавление функции. В настоящее время Discourse позволяет указывать только один адрес электронной почты, который используется и для envelope-from, и для reply-to. Если сайт хочет использовать свой собственный домен SMTP для отправки писем, но при этом желает, чтобы ответы на письма отправлялись на другой домен (например, Gmail), то отправленные письма не пройдут проверку DMARC. Разделение этих двух заголовков позволит избежать сбоя DMARC, а также сохранить возможность обработки писем с ошибками доставки.
Не совсем понятно, как в данной ситуации будут обрабатываться недоставленные письма. Отказы приходят на адрес из envelope-from, а не на адрес, указанный в заголовке Reply-To. Поэтому, если ваш envelope-from не способен обрабатывать письма с VERP-тегами, вы всё равно останетесь в сложном положении.
В теме, на которую вы ссылаетесь, вы не объясняете, почему подписание DKIM для домена в заголовке From: не работает. Это должно обеспечивать соответствие DMARC, даже если SPF не проходит. Именно этот подход я бы выбрал, если бы оказался на вашем месте (либо, альтернативно, отправился бы к администраторам входящего SMTP-сервера yyy.com с вилами; какой же MTA не поддерживает никакой вид адресации с деталями?!?)
Это сработает, потому что MTA поддерживает catch-all. Хотя он не поддерживает VERP, его можно настроить на пересылку всех неопределённых писем на конкретный адрес, так что ответы об ошибках доставки не будут потеряны.
Кроме того, если мы разделим envelope-from и reply-to, то envelope-from не обязательно должен содержать VERP-адрес. Он может быть простым, например discourse@yyy.com. Таким образом, при возврате письма оно придёт на discourse@yyy.com, что не нарушит SPF.
reply-to может содержать другой адрес, поддерживающий VERP, например discourse-yyy+sdfkj33@gmail.com. Если доставка успешна, то при ответе пользователя письмо попадёт на Gmail-сервер, который поддерживает VERP, и это не нарушит DMARC, поскольку from остаётся yyy.com.
Я согласен, но мы их не создаём. Поскольку они используют адресацию catch-all, они не поддерживают VERP. К сожалению, такая ситуация. Я надеюсь, что благодаря небольшой доработке Discourse сможет поддерживать более разнообразную экосистему. Многие небольшие сайты, использующие Gmail для обработки ответов, окажутся в такой ситуации.
Если ваш MTA поддерживает catch-all, почему вы не можете перенаправлять ответы с помощью той же функции и вообще отказаться от Gmail?
Адрес envelope-from — это тот, который обязан поддерживать VERP, потому что единственный надёжный способ определить причину недоставки — это информация в адресе envelope-from оригинального письма, как ранее объяснил Майкл.
Я сомневаюсь в этом утверждении. Использование адреса Gmail для ответов — это ненадёжное решение, и всегда было таковым; mail-receiver — гораздо более прямой, надёжный и менее проблемный способ обработки ответов (и уведомлений о недоставке).
Даже для тех небольших сайтов, которые используют Gmail, самые крошечные, вероятно, игнорируют Условия использования и используют Gmail также для ретрансляции исходящей почты, а подавляющее большинство остальных, скорее всего, не зависят от MTA, который не поддерживает детальную адресацию.
Потому что «catch-all» настроен для домена, и для Discourse используется только один адрес электронной почты.
Не обязательно. Я сейчас использую его без VERP, и всё работает. Моя проблема в том, что я не могу позволить пользователям отвечать напрямую на Gmail без сбоев SPF/DMARC из-за того, как Discourse устанавливает адреса envelope-from и reply-to. Вместо этого мне приходится заставлять MTA пересылать ответ в Gmail. Если бы я мог настроить прямой ответ на Gmail (без сбоев DMARC/SPF), то мог бы использовать VERP для защиты ответов, хотя в случае возврата писем VERP всё равно игнорировался бы. Это всё равно безопаснее, чем текущая реализация.
Это не вариант, так как я объяснил это здесь. Использовать Gmail практично только для входящей почты. Настройка собственного прямого входящего MX, когда у вас уже есть MX от хостинг-провайдера, может быть сложной задачей для новичков. Прямые ответы через Gmail гораздо проще и менее подвержены ошибкам.
Возможно, я упускаю что-то в вашей логике. Я вижу только преимущества в разделении адресов envelope-from и reply-to: это поддерживает более разнообразные экосистемы, повышает безопасность и помогает избежать сбоев SPF/DMARC.
Мой вывод таков: правильный способ решения вашей проблемы, судя по описанию, — это настройка DKIM. Усложнять конфигурацию почты и делать её ещё более подверженной ошибкам в вашем случае, на мой взгляд, нецелесообразно.
DKIM уже настроен, проблема заключается в сбое SPF.
Добавление дополнительного поля для разделения адресов envelope-from и reply-to обеспечит большую гибкость и позволит SPF проходить проверку (что не произойдет, если используется SMTP-сервер, пересылающий письма, или не поддерживающий VERP). Это поле можно скрыть в интерфейсе или по умолчанию устанавливать его равным адресам envelope-from и reply-to, если администраторы не примут решение изменить его вручную. Описание может содержать ссылку на эту страницу. Однако я не вижу, как это может ухудшить ситуацию — оно может только улучшить её: либо адреса совпадают (в этом случае SPF не пройдет в любых описанных здесь сценариях), либо это повысит доставляемость писем.