Иногда электронное письмо не доходит, если оно отправлено получателю, который использует outlook.com система для своего почтового сервера. Их запись MX разрешается нормально, но их запись A (что-то вроде example-com.mail.protection.outlook.com) время вышло.
С помощью sendmail здесь, и я не эксперт. Я унаследовал конфигурацию и мало что знаю о настройках. Я точно знаю, что он не редактировался годами и никаких признаков проблемы не было.
Не знаю, намеренно ли это, но ответ от dig example-com.mail.protection.outlook.com время ожидания истекает через 15 секунд, а затем более поздние операции поиска завершаются успешно.
Мы используем наш собственный DNS-сервер BIND для кэширования, который также не подвергался перенастройке по крайней мере так долго.
Похоже, что наша система sendmail перестает работать после того, как хост не найден для example-com.mail.protection.outlook.com. Пригоден ли этот постоянный отказ? Следует ли вместо этого заменить его на временный отказ? Какой стандарт? Неправильно ли outlook.com или наша sendmail?
редактировать
Для справки, вот соответствующие записи журнала из maillog, с скрытой конфиденциальной информацией example.com представляет сервер-получатель, и example.net представляет нашу собственную domain.
Jun 16 09:28:28 myhostname sendmail[8613]: [ID 801593 mail.info] s5GDSOZ4008613: from=websusr, size=16975, class=0, nrcpts=2, msgid=<201406161328.s5GDSOZ4008613@myhostname.example.net>, relay=websusr@localhost
Jun 16 09:28:28 myhostname sendmail[8617]: [ID 801593 mail.info] s5GDSSIP008617: from=<websusr@myhostname.example.net>, size=17222, class=0, nrcpts=2, msgid=<201406161328.s5GDSOZ4008613@myhostname.example.net>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Jun 16 09:28:28 myhostname sendmail[8613]: [ID 801593 mail.info] s5GDSOZ4008613: to="John Doe" <john@example.com>, ctladdr=websusr (60001/60001), delay=00:00:04, xdelay=00:00:00, mailer=relay, pri=76975, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s5GDSSIP008617 Message accepted for delivery)
Jun 16 09:32:09 myhostname sendmail[8618]: [ID 801593 mail.info] s5GDSSIP008617: to=<john@example.com>, ctladdr=<websusr@myhostname.example.net> (60001/60001), delay=00:03:41, xdelay=00:03:40, mailer=esmtp, pri=77440, relay=example-com.mail.eo.outlook.com., dsn=5.1.2, stat=Host unknown (Name server: example-com.mail.eo.outlook.com.: host not found)
Jun 16 09:32:09 myhostname sendmail[8618]: [ID 801593 mail.info] s5GDSSIP008617: s5GDW9IP008618: DSN: Host unknown (Name server: example-com.mail.eo.outlook.com.: host not found)
Также выходы dig на данный момент, хотя на данный момент проблема не возникает, это позволяет вам видеть mx запись.
>dig example.com mx
; <<>> DiG 9.3.2 <<>> example.com mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1448
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN MX
;; ANSWER SECTION:
example.com. 3461 IN MX 0 example-com.mail.protection.outlook.com.
example.com. 3461 IN MX 10 example-com.mail.eo.outlook.com.
;; AUTHORITY SECTION:
example.com. 86261 IN NS ns1.example.org.
example.com. 86261 IN NS ns2.example.org.
;; Query time: 0 msec
;; SERVER: 10.0.0.109#53(10.0.0.109)
;; WHEN: Thu Jul 3 09:32:08 2014
;; MSG SIZE rcvd: 215
>dig example-com.mail.protection.outlook.com
; <<>> DiG 9.3.2 <<>> example-com.mail.protection.outlook.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1734
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 6
;; QUESTION SECTION:
;example-com.mail.protection.outlook.com. IN A
;; ANSWER SECTION:
example-com.mail.protection.outlook.com. 10 IN A 207.46.163.170
example-com.mail.protection.outlook.com. 10 IN A 207.46.163.215
example-com.mail.protection.outlook.com. 10 IN A 207.46.163.138
;; AUTHORITY SECTION:
mail.protection.outlook.com. 1800 IN NS ns1-proddns.glbdns.o365filtering.com.
mail.protection.outlook.com. 1800 IN NS ns2-proddns.glbdns.o365filtering.com.
;; ADDITIONAL SECTION:
ns1-proddns.glbdns.o365filtering.com. 30 IN A 207.46.100.42
ns1-proddns.glbdns.o365filtering.com. 30 IN A 207.46.163.143
ns1-proddns.glbdns.o365filtering.com. 30 IN A 207.46.163.176
ns2-proddns.glbdns.o365filtering.com. 30 IN A 207.46.163.176
ns2-proddns.glbdns.o365filtering.com. 30 IN A 207.46.100.42
ns2-proddns.glbdns.o365filtering.com. 30 IN A 207.46.163.143
;; Query time: 464 msec
;; SERVER: 10.0.0.109#53(10.0.0.109)
;; WHEN: Thu Jul 3 09:33:30 2014
;; MSG SIZE rcvd: 276
>dig example-com.mail.eo.outlook.com
; <<>> DiG 9.3.2 <<>> example-com.mail.eo.outlook.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 940
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 12
;; QUESTION SECTION:
;example-com.mail.eo.outlook.com. IN A
;; ANSWER SECTION:
example-com.mail.eo.outlook.com. 10 IN A 207.46.163.138
example-com.mail.eo.outlook.com. 10 IN A 207.46.163.170
example-com.mail.eo.outlook.com. 10 IN A 207.46.163.247
;; AUTHORITY SECTION:
mail.eo.outlook.com. 5450 IN NS ns1-prodeodns.glbdns.o365filtering.com.
mail.eo.outlook.com. 5450 IN NS ns2-prodeodns.glbdns.o365filtering.com.
;; ADDITIONAL SECTION:
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 157.55.234.42
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 157.56.112.42
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.100.42
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.143
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.176
ns1-prodeodns.glbdns.o365filtering.com. 30 IN A 65.55.169.42
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 65.55.169.42
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 157.55.234.42
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 157.56.112.42
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.100.42
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.143
ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.176
;; Query time: 248 msec
;; SERVER: 10.0.0.109#53(10.0.0.109)
;; WHEN: Thu Jul 3 09:33:45 2014
;; MSG SIZE rcvd: 368
>
Если разрешение DNS просто истекает, и ответ от DNS-сервера вообще не приходит, или возвращается SERVFAIL, то предполагается, что сообщение будет поставлено в очередь и будет повторено позже.
Если разрешение DNS возвращает NXDOMAIN (имя не существует), сообщение должно быть возвращено немедленно.
Видеть RFC 5321, раздел 5.1:
Поиск сначала пытается найти запись MX, связанную с именем. Если запись CNAME найдена, полученное имя обрабатывается, как если бы это было исходное имя. Если возвращается несуществующая ошибка домена, эта ситуация ДОЛЖНА быть сообщена как ошибка. Если возвращается временная ошибка, сообщение ДОЛЖНО быть поставлено в очередь и повторено позже (см. Раздел 4.5.4.1).
В вашем случае вы должны посмотреть, почему ваш DNS-сервер периодически дает сбой. Вы также должны проверить журналы sendmail, чтобы точно узнать, что он видел, когда пытался выполнить разрешение DNS.