Почему "dig gmail.com mx" не возвращает домен "smtp.gmail.com"?
dig gmail.com возвращает это:
;; ANSWER SECTION:
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
Как насчет smtp.gmail.com, почему он не включен? Есть ли способ найти его через какую-то утилиту? Или это то, что можно найти только в документации по gmail?
Тот же вопрос касается других почтовых сервисов.
Моя первоначальная цель - найти все SMTP-серверы провайдера электронной почты.
3 ответа
Как насчет smtp.gmail.com, почему он не включен?
Так как smtp.gmail.com не получает электронную почту для домена gmail.com. Вы запросили запись MX для gmail.com. Ответ, который вы получили, был именно таким. Запись MX указывает, какие хосты получают электронную почту для данного домена. Запись MX ничего не говорит о SMTP-серверах отправки клиента и т. Д. Хост с именем smtp.example.com не должен быть хостом, который получает электронную почту для указанного домена. Хост, который получает электронную почту для домена, может быть буквально назван как угодно.
Если вы хотите знать, какие хосты получают электронную почту для данного домена, выполните поиск записи MX, как и вы. Если вы хотите узнать, какой хост клиент определенного провайдера электронной почты должен использовать для отправки электронной почты, обратитесь к документации хостера электронной почты.
Моя первоначальная цель - найти все SMTP-серверы провайдера электронной почты.
Ты не можешь
Как справедливо указывает joeqwerty, это не показывает smtp.google.com потому что MX запись указывает, куда почтовые серверы должны отправлять сообщения, предназначенные для этого домена. Это не то же самое, что серверы, которые должны использоваться почтовым клиентом конечного пользователя для передачи исходящих сообщений в произвольные пункты назначения.
RFC 6186 описывает способ автоматического обнаружения SMTP-сервера с SRV записей. Проблема в том, что большую часть жизни Интернета настройки SMTP-сервера передавались через документацию, а не через DNS. Вы не можете полагаться на эту информацию, присутствующую. Современные почтовые клиенты будут пытаться автоматически определять настройки SMTP-сервера на основе предоставленного вами суффикса домена, но в случае неудачи пользователь должен полагаться на документацию этой компании, как обычно. Эта информация не доступна иным образом, в электронном или ином виде.
представление: идентифицирует MSA, используя [RFC4409]. Обратите внимание, что это относится к соединениям как с защитой транспортного уровня (TLS), так и без нее [RFC5246], как определено для SMTP в [RFC3207].
Пример: служебная запись
_submission._tcp SRV 0 1 587 mail.example.com.
В данном конкретном случае запрос был _submission._tcp.gmail.com с типом SRV,
$ dig _submission._tcp.gmail.com SRV
; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> _submission._tcp.gmail.com SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8996
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_submission._tcp.gmail.com. IN SRV
;; ANSWER SECTION:
_submission._tcp.gmail.com. 86400 IN SRV 5 0 587 smtp.gmail.com.
;; Query time: 9 msec
;; SERVER: 66.228.62.5#53(66.228.62.5)
;; WHEN: Sun Jul 02 03:17:11 UTC 2017
;; MSG SIZE rcvd: 89