Мы заметили периодически повторяющиеся проблемы в нашей конфигурации sendmail. Сценарий состоит в том, что мы получаем сообщение из Интернета с одним из наших пользователей в списке «Кому:», а у одного из других пользователей в списке «Кому:» есть домен с проблемой DNS. В этом случае sendmail получает ошибку DNS на неверном адресе и завершает работу с "ошибкой поиска имени хоста", поэтому сообщение застревает в нашей очереди на несколько дней и никогда не доставляется получателю в нашей системе.
Например, если я отправлю сообщение с этой строкой To::
To: cheeks@swcp.com, bubbatest@lovelacesandia.com
swcp.com - это локальный домен, обслуживаемый этим сервером, а «cheeks» имеет локальный псевдоним, указывающий на «cheeks @ ebi2». lovelacesandia.com - это нелокальный домен с проблемой (в настоящее время все запросы к нему приводят к SERVFAIL). У исходной почтовой программы, вероятно, есть копия этого сообщения, застрявшая в их собственной очереди, потому что они также не могут связаться с lovelacesandia.com. Копия сообщения, которая застряла в моей очереди, имеет только одного получателя:
RPFDA:cheeks@ebi2
Вот результат "sendmail -v -d8-9.5 -qRcheeks"
Running /var/spool/mqueue/t7QHX1uB080255 (sequence 1 of 1)
host_map_lookup(swcp.com) => dns_getcanonname(swcp.com, trymx=1)
dns_getcanonname: trying swcp.com. (AAAA)
dns_getcanonname: trying swcp.com. (A)
dns_getcanonname: swcp.com
FOUND swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(ebi2) => dns_getcanonname(ebi2, trymx=1)
dns_getcanonname: trying ebi2.swcp.com (AAAA)
dns_getcanonname: trying ebi2.swcp.com (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
getmxrr([ebi2.swcp.com], droplocalhost=1)
dns_getcanonname(ebi2.swcp.com, trymx=0)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
cheeks@ebi2... Connecting to ebi2.swcp.com. via smtp...
220 ebi2.swcp.com ESMTP Sendmail 8.15.1/8.14.9; Wed, 26 Aug 2015 11:44:59 -0600 (MDT)
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-AUTH PLAIN LOGIN
250-DELIVERBY
250 HELP
>>> MAIL From:<cheeks@swcp.com> SIZE=1672
250 2.1.0 <cheeks@swcp.com>... Sender ok
host_map_lookup(ebi2.swcp.com) => dns_getcanonname(ebi2.swcp.com, trymx=1)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
>>> RCPT To:<cheeks@ebi2.swcp.com>
>>> DATA
250 2.1.5 <cheeks@ebi2.swcp.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(lovelacesandia.com) => dns_getcanonname(lovelacesandia.com, trymx=1)
dns_getcanonname: trying lovelacesandia.com. (AAAA)
dns_getcanonname: trying lovelacesandia.com. (A)
dns_getcanonname: trying lovelacesandia.com. (MX)
dns_getcanonname: trying lovelacesandia.com.swcp.com (AAAA)
FAIL (2)
lovelacesandia.com: Name server timeout
timeout writing message to ebi2.swcp.com.
cheeks@ebi2... Deferred: Name server: ebi2.swcp.com.: host name lookup failure
Closing connection to ebi2.swcp.com.
Это с Sendmail 8.15.1 на FreeBSD 10.1. Я подозреваю, что это состояние существует давно, но мы только недавно диагностировали его. Большинство сообщений, соответствующих этому сценарию, оказываются спамом, поэтому никого это не волнует. Но иногда кто-то отправляет почту большому списку людей (без использования BCC), и один из адресов становится плохим.
Если бы мы пытались доставить по поддельному адресу, я бы понял, почему у нас возникла проблема. Я не понимаю, почему мой sendmail заботится о поддельном адресе в заголовке To :, для которого мы не будем пытаться доставить.
У нас есть следующие ОСОБЕННОСТИ, которые, как я думал, могут быть задействованы:
FEATURE(blacklist_recipients)
FEATURE(`delay_checks', `friend', `n')
Я провел тесты с удалением их обоих и получил тот же результат.
Если у кого-то есть идеи о том, что вызывает это, или как это уменьшить, я был бы признателен. Спасибо,
отметка
Меня тоже поразила эта проблема.
После некоторого времени поиска одним из возможных обходных путей является использование этого фрагмента в sendmail.mc:
FEATURE(`nocanonify', `canonify_hosts')
CANONIFY_DOMAIN(`$=m')
Это может иметь побочные эффекты, как подробно описано в документации, и я не совсем уверен, является ли это лучшим решением проблемы. Но пока это работает.
С некоторыми rlytest эксперименты, sendmail не касается получателей заголовков; однако в вашем случае плохой домен должен был быть получателем, иначе адрес не будет пропущен через поисковую машину? Поскольку sendmail временно откажется от всего, что предназначено для домена, который возвращает SERVFAILMilter - это независимо от вашего лучшего выбора; настройка milter-regex - это один из вариантов:
dnl for sendmail.mc
INPUT_MAIL_FILTER(`milter-regex', `S=unix:/var/spool/milter-regex/sock, T=S:30s;R:2m')dnl
И когда этот демон запущен и использует этот файл сокета, milter-regex.conf по строкам:
discard
envrcpt /@lovelacesandia\.com>/i
Усложняющим фактором будет то, что эти сообщения доставляются непосредственно в sendmail двоичный файл в качестве агента отправки почты, и в этом случае submit.cf Конфигурация должна быть изменена, чтобы вызвать milter, или дать указание не выполнять поиск по домену, а вместо этого передавать все основному агенту почтового транспорта, который затем может выполнить сброс при необходимости.