Должен DNS тайм-аут для приведения к постоянному почтовому отказу?

Иногда электронное письмо не проходит при отправке в получателя, который использует outlook.com система для их почтового сервера. Их прекрасная твердость записи MX, но их запись (что-то как example-com.mail.protection.outlook.com) испытывает таймаут.

Используя sendmail здесь, и я не опытен. Я наследовал конфигурацию, и не знайте много о настройках. Одна вещь, которую я знаю, состоит в том, что это не было отредактировано в течение многих лет, и не было никакого признака проблемы.

Я не знаю, является ли это намеренным, но ответ от dig example-com.mail.protection.outlook.com испытывает таймаут после 15 секунд и затем позже роет, успешны.

Мы используем наш собственный BIND сервер DNS для кэширования, которое также не было реконфигурировано для, по крайней мере, настолько долго.

Кажется, что наша 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

>
1
задан 3 July 2014 в 16:40
1 ответ

Если DNS-разрешение просто выдает тайм-аут, и ответ никогда не возвращается с DNS-сервера вообще, или возвращается SERVFAIL, то сообщение должно быть поставлено в очередь и попробовать снова позже.

Если разрешение DNS возвращает NXDOMAIN (имя не существует), то сообщение должно быть возвращено немедленно.

Смотрите RFC 5321, раздел 5.1:

Сначала поиск пытается найти MX-запись, связанную с именем. Если найдена запись CNAME, полученное имя обрабатывается так, как если бы это было первоначальное имя. Если возвращается несуществующая ошибка домена, то об этой ситуации ДОЛЖНА быть сообщена как об ошибке. Если возвращается временная ошибка, сообщение ДОЛЖНО быть поставлено в очередь и перепроверено позже (см. Раздел 4.5.4.1).

В вашем случае необходимо выяснить, почему ваш DNS-сервер периодически выходит из строя. Вы также должны проверить журналы sendmail, чтобы узнать, что именно он видел, когда пытался выполнить разрешение DNS.

.
5
ответ дан 3 December 2019 в 17:07

Теги

Похожие вопросы