Назад | Перейти на главную страницу

sendmail использует обратный путь вместо исходного адреса

У меня есть клиент, который жалуется на электронные письма, помеченные как спам.

Смотрю шапку. Он показывает правильный From: reg@company.com

Однако ему не нравится обратный путь.

Return-Path: <apache@servername.mycompany.com>
Received-SPF: neutral (google.com: x.x.x.x is neither permitted nor denied by domain of apache@servername.mycompany.com) client-ip=x.x.x.x;
Authentication-Results: mx.google.com; spf=neutral (google.com: x.x.x.x is neither permitted nor denied by domain of apache@servername.mycompany.com) smtp.mail=apache@servername.mycompany.com

Как настроить sendmail на использование адреса «От» в качестве обратного пути?

Из книги о летучих мышах (страница 1165):

Заголовок Return-Path: предназначен для отображения адреса реального отправителя в конверте в отличие от отправителя, используемого для ответа (заголовки From: и Reply-To:). При публикации новостей Usenet, например, Return-Path: показывает «новости», а From: показывает адрес отправившего сообщение пользователя. Но в целом Return-Path: никогда не следует использовать для ответа на почту. Он предназначен для использования исключительно для уведомления об ошибках доставки.

У вашего клиента нет проблем с заголовком Return-Path :. Ни с SPF, так как результат нейтральный, как нам говорят заголовки. Ваш клиент должен принять тот факт, что предполагаемые получатели рассматривают то, что он отправляет, как спам.

Если это действительно ложное срабатывание, подумайте о правильной настройке SPF и DKIM записи для домена и посмотрите, улучшится ли ситуация.

Похоже, ваше электронное письмо отправлено автоматическим отправителем, который отправляет его с помощью одного из серверов Google. Возможно, он подключается к GMail для отправки сообщения. На вашем сервере есть запись SPF, которая не включает список SPF Google и не указывает, что она должна применяться. Может помочь включение заголовка отправителя для apache@servername.mycompany.com.

Существует ряд факторов, из-за которых ваша электронная почта будет выглядеть как спам еще до того, как вы начнете ее отправлять.

  • У вас есть статический адрес с записью PTR, возвращающей ваше имя хоста, или имя в другой записи A для адреса? (Работает ли обратная проверка DNS?)
  • Ваш почтовый сервер объявляет о себе, используя то же имя, которое возвращает запись PTR?
  • Есть ли у вашего почтового сервера запись SPF, позволяющая отправлять электронную почту?
  • Ваш адрес указан в list.openwl.org?

Неудача первых двух тестов явно указывает на спам или автоматический источник почты. Электронная почта от человека к человеку почти всегда проходит эти тесты, в то время как спам часто не проходит. Следующие два теста указывают на отсутствие спама.

После того, как вы начали отправлять электронное письмо, применяются другие тесты.

  • И в адресе обратного пути (адрес конверта), и в адресе отправителя должна быть запись MX, указывающая на рабочий почтовый сервер.
  • Адрес обратного пути должен совпадать с заголовком адреса отправителя или отправителя.
  • Оба домена (если они разные) должны иметь рабочий адрес почтмейстера.
  • Оба домена (если они разные) должны иметь записи SPF, разрешающие почту с отправляющего сервера.
  • Может учитываться предыдущая история обоих адресов электронной почты и их доменов (автоматический белый список / автоматический черный список).
  • Имеется ли у сообщения действующая подпись DKIM.
  • Любые другие правила, которые администратор электронной почты сочтет необходимыми.

Я обнаружил, что я получаю относительно высокий процент отказов в документах, подписанных DKIM, от автоматических отправителей. В основном это связано с тем, что открытые ключи недоступны в DNS.