Наш отдел маркетинга заключает договор со службой, которая будет отправлять электронные письма потенциальным клиентам от нашего имени. Из того, что я почерпнул из их документации, похоже, что они делают это через заголовок Sender (т.е. заголовок From содержит адрес в нашем домене, а заголовок Sender содержит адрес из их домена). Это помещает тег «через» или «от имени» в отображение некоторых почтовых клиентов.
Они дают нам возможность установить запись DKIM в нашем домене и заставить их отправлять электронные письма прямо из нашего домена со своих серверов. (Предположительно, нам также придется добавить их в наш SPF, хотя они не упомянули об этом.)
Я понимаю общие последствия всего этого, но они заявляют, что пытаются продвинуть опцию прямой отправки, что сообщения «через» или «от имени» с большей вероятностью будут помечены как спам. Так ли это на практике?
Другими словами, будут ли сообщения с заголовком Sender отличным от заголовка From с большей вероятностью быть помечены как спам, чем сообщения, отправленные только с заголовком From (при условии, что записи SPF не мешают)?
В Sender это стандарт поле отправителя указанный в формате Интернет-сообщения (RFC 5322, 3.6.2) и, следовательно, не следует рассматривать как ошибку. Иногда это даже обязательно.
Поля отправителя сообщения состоят из поля отправителя, поля отправителя (если применимо) и, возможно, поля ответа. Поле from состоит из имени поля
Fromи разделенный запятыми список одной или нескольких спецификаций почтовых ящиков. Если поле from содержит более одной спецификации почтового ящика в списке почтовых ящиков, тогда поле отправителя, содержащее имя поляSenderи одна спецификация почтового ящика ДОЛЖНЫ появиться в сообщении. В любом случае МОЖЕТ быть включено необязательное поле ответа, которое содержит имя поля.Reply-Toи список из одного или нескольких адресов, разделенных запятыми.Поля отправителя указывают почтовый ящик (а) источника сообщения. В
From:Поле определяет автора (ов) сообщения, то есть почтовый ящик (я) человека (ей) или системы (ов), ответственных за написание сообщения. ВSender:Поле указывает почтовый ящик агента, ответственного за фактическую передачу сообщения.
Я не могу быть полностью уверен в том, что обнаружение спама дает оценку существованию Sender только заголовок, но мы можем начать с исследования SpamAssassin Rule QA Например. Правило для __HAS_SENDER в настоящее время не активен, т. е. не оценивает сообщение.
Если подписано, DKIM проверяет From: поле напротив подписи и подпись против открытого ключа, предоставленного в DNS для этого домена и селектор. Подпись DKIM должна соответствовать From поле, есть ли Sender присутствует или нет. Эти двое не исключают друг друга, но сегодня рекомендуется иметь подписи DKIM - и применять DKIM с помощью DMARC. Я бы рекомендовал иметь отдельный селектор (и ключи подписи) для каждого стороннего поставщика услуг.
SPF, с другой стороны, вообще ничего не проверяет по заголовкам писем. Он проверяет, используется ли домен в отправитель конверта (т.е. адрес, используемый в SMTP MAIL FROM: command) перечисляет этот MTA как разрешенного отправителя. Пока RFC 6854 позволяет иметь несколько адресов в From поле MAIL FROM всегда имеет только один адрес и всегда запускает новую почтовую транзакцию, очищая всех получателей и почтовые данные (RFC 5321, 3.3).
Следовательно, отправляющий сервер может использовать собственный домен в отправитель конверта, и в идеале он будет соответствовать Sender заголовок, а From соответствует DKIM. Затем конечный целевой сервер записывает отправителя конверта, вставляя третий заголовок Return-Path, в качестве информации трассировки (RFC 5321, 4.4). Поскольку эта информация, которая в настоящее время сохраняется только в конечном пункте назначения, может измениться во время передачи, SpamAssassin имеет предложение для хранения этой информации на каждом Received заголовок. Это не так широко распространено, но SpamAssassin поддерживает его с версии 3.0.3.