Иногда электронное письмо не проходит при отправке в получателя, который использует 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
>
Если DNS-разрешение просто выдает тайм-аут, и ответ никогда не возвращается с DNS-сервера вообще, или возвращается SERVFAIL, то сообщение должно быть поставлено в очередь и попробовать снова позже.
Если разрешение DNS возвращает NXDOMAIN (имя не существует), то сообщение должно быть возвращено немедленно.
Смотрите RFC 5321, раздел 5.1:
Сначала поиск пытается найти MX-запись, связанную с именем. Если найдена запись CNAME, полученное имя обрабатывается так, как если бы это было первоначальное имя. Если возвращается несуществующая ошибка домена, то об этой ситуации ДОЛЖНА быть сообщена как об ошибке. Если возвращается временная ошибка, сообщение ДОЛЖНО быть поставлено в очередь и перепроверено позже (см. Раздел 4.5.4.1).
В вашем случае необходимо выяснить, почему ваш DNS-сервер периодически выходит из строя. Вы также должны проверить журналы sendmail, чтобы узнать, что именно он видел, когда пытался выполнить разрешение DNS.
.