Почему DMARC работает с адресом отправителя, а не отправитель конверта (Return-Path)?
Сложение использования памяти всех процессов не будет обычно приводить к значимым результатам. Это оставит двух крупных пользователей памяти пропавшими без вести, системный кэш и резервный список. Вы не можете объяснить использование памяти просто сложением списка чисел. Система управления памятью слишком сложна для этого.
Думайте о SPF и DKIM, как о способе проверки пути сообщения, и думайте о DMARC, как о расширении, которое также проверяет отправителя сообщения. Думайте об этом, как о доставке письма FedEx. Легко проверить, откуда был отправлен конверт, и что курьер был законным, но это не предоставляет способа доказать, что письмо внутри конверта действительно от человека, чье имя напечатано на нем.
Ваш веб-сервер является действительным SMTP сервером для mywebserver.com и что ваш адрес отправителя является законным, но этого недостаточно, чтобы другие серверы доверяли, что у вас есть разрешение на отправку под именем website-user@gmail.com . Откуда GMail знает, что ваш сервер не был взломан или иным образом использован для злоумышленных целей? Серверы Gmail не будут слепо доверять вам, чтобы вы отправляли почту как один из их пользователей - если только вы не находитесь на их хостинге, и тогда у вас, вероятно, будут проблемы с отправкой почты в Yahoo.
Чтобы ответить на вашу первую часть вопроса, да, очень вероятно, что именно по этой причине GMail классифицирует его как спам. Самые старые формы спам-центра вокруг подмены адреса "From". Это то, что большинство пользователей видят, когда получают сообщение, и это основное поле, которому они хотят доверять. Когда сообщение с законного почтового сервера отправляется с адреса "From", который не принадлежит этому почтовому серверу, это все еще красный флаг.
Как вы уже упоминали, DMARC работает с адресом "From", как с частью спецификации. Конечно, это усложняет написание веб-приложений, которые посылаются от чьего-то имени, но в том-то и дело. Что касается , почему они делают это - ну, это зависит от разработчиков спецификации, но это компромисс. Они идут по высокому пути и создают систему, которая работает очень хорошо, если вы остаетесь в рамках этого ограничения. Возможно, будущие механизмы найдут способ обойти это.
Неудачное решение - использовать только те адреса, которые у вас есть под контролем. Чтобы ответить на третий вопрос, подпишите сообщения своим доменным именем и укажите в теле, что оно было отправлено от имени website-user@gmail.com. В противном случае вам придется попросить получателей добавить адрес в их белый список. Это не очень весело для законного разработчика веб-приложений, но это защитит неприкосновенность почтового ящика получателя. Вам может повезти, если вы используете заголовок Reply-To с адресом электронной почты веб-пользователя.
Обсуждается это ограничение на этом потоке DMARC.
В то же время, вы можете попытаться убедиться, что ваш сервер не попал в черный список ни на одной из RBL. Это может быть, что вы можете обмануть DMARC, но все равно пройти через некоторые спам-фильтры, если у вас достаточно хорошая репутация... но я бы не стал на это полагаться.
.Существуют два "почему" вопросы:
- , Почему почтовый сервер получения выполняет регистрацию этого способа
- , потому что это - то, что раздел 3.1 из RFC 7489 говорит, чтобы сделать
- , Почему DMARC была разработана тот путь?
- , потому что люди, которые разработали его, по-видимому, не читали раздел 3.6.2 из RFC 5322 , или неправильно истолковал его или проигнорировал его.
, Что раздел ясно устанавливает, что Sender: заголовок, когда существующий, берет приоритет над From: заголовок в целях определить сторону, ответственную за отправку сообщения:
"Отправитель": поле указывает почтовый ящик агента, ответственного за фактическую передачу сообщения. Например, если бы секретарь должен был отправить сообщение за другим человеком, то почтовый ящик секретаря появился бы в "Отправителе": поле и почтовый ящик фактического автора появились бы в "От": поле. Если инициатор сообщения может быть обозначен отдельным почтовым ящиком, и автор и передатчик идентичны, "Отправитель": поле SHOULD NOT использоваться. Иначе оба поля SHOULD появляются.
Контраст это с объяснением, данным в [1 112] RFC 7489 :
DMARC аутентифицирует использование RFC5322. От [1 146] домен путем требования, чтобы это соответствовало (быть выровненное) Аутентифицируемый Идентификатор. RFC5322. От [1 147] домен был выбран как центральные идентификационные данные механизма DMARC, потому что это - необходимое поле заголовка сообщения и поэтому гарантируемый присутствовать в совместимых сообщениях, и Самые Почтовые Агенты пользователя (MUAs) представляют RFC5322. От [1 148] поле как инициатор сообщения и рендеринга некоторые или все это содержание поля заголовка к конечным пользователям.
я утверждаю, что эта логика испорчена, как [1 113], RFC 5322 продолжает вызывать эту ошибку явно:
Примечание: информация о передатчике всегда присутствует. Отсутствие "Отправителя": поле иногда по ошибке берется, чтобы означать, что агент, ответственный за передачу сообщения, не был указан. Это отсутствие просто означает, что передатчик идентичен автору и поэтому избыточно не помещается в "Отправителя": поле.
я полагаю, что DMARC повреждается дизайном, потому что
- он объединяет полномочия для отправки и доказательство авторства ;
- это неправильно истолковывает предшествующий RFCs, и
- при этом это повреждает любой ранее совместимый список-serv, который идентифицировал себя путем добавления его собственного
Sender:заголовок.
, Если Sender: поле присутствует, DMARC должен сказать для аутентификации , что поле и игнорирует From: поле. Но это не то, что это говорит, и поэтому я полагаю, что это повреждается.
RFC 7489 продолжается:
Таким образом, это поле является тем, используемым конечными пользователями для идентификации источника сообщения, и поэтому является главной целью для злоупотребления.
Это просто неправильно (в контексте выравнивания по ширине игнорирования Sender: заголовок). В то время, когда DMARC был разработан, общие почтовые клиенты будут обычно отображать комбинацию информации от Sender: и From: поля, что-то как [1 149] От [1 122] name-for-mailing-list@server от имени [1 123] user@original.domain . Таким образом, это было всегда ясно пользователю, который был ответственен за отправку сообщения, они смотрели на.
Предположения, который Reply-To: соответствующая замена, также испорчены, потому что тот заголовок широко неправильно истолкован как "дополнительный получатель", а не "заменяющий получатель", и замена исходного отправителя Reply-To: повредила бы функциональность для [1 124] они пользователи.
1) да, скорее всего сбой dmarc приведет к тому, что gmail будет спаковать вашу почту
2) также был бы заинтересован в ответе на этот вопрос
3) я бы (и мы это делаем) использовал поле ответа для адреса клиента, наша почта выглядит так:
с: website@mydomain.com
на: user@mydomain.com
тема: контактная форма
ответ: customer-addy@somewhere.com
надеюсь, это поможет
.