
В первых трех пакетах клиент (192.168.0.253) устанавливает TCP
соединение с 25 портом SMTP сервера (192.168.0.89). Затем клиент в пакетах с
4-го по 17-ый переедает серверу письмо для релейной отправки и предлагает
серверу завершить соединение командой QUIT. Анализируем поведение
сервера. В пакетах 18-20 сервер устанавливает TCP соединением со своим DNS
сервером (192.168.0.1), а в пакете 21 спрашивает у DNS сервера: кто является
MX домена mail.ru. в пакете 22 DNS сервер отвечает почтовому серверу, что MX
в домене mail.ru является узел mxs.mail.ru, в том же пакете DNS сервер
сообщает почтовому серверу, что IP адрес узла mxs.mail.ru – 194.67.23.20.
Затем в пакете 23 почтовый сервер дает почтовому клиенту отклик 221 в ответ
на команду QUIT и посылает пакет 24 с приглашением закрыть соединение, что
клиент и квитирует в пакете 25. В 26-ом пакете почтовый сервер устанавливает
TCP соединение с почтовым сервером mxs.mail.ru с целью отправки ему
полученного письма, тем временем в пакетах 27-30 почтовый сервер закрывает
TCP соединением с DNS сервером. В пакетах 31-32 соединение между нашим
релейным сервером и mxs.mail.ru устанавливается, после чего в пакетах 33-43
наш релейный сервер передает письмо mxs.mail.ru, после чего в пакетах 44-49
соединение между релейным сервером и mxs.mail.ru корректно разрывается.
Наш почтовый клиент разрывает свое исходное соединение с релейным
сервером относительно запоздало, в пакетах 50-51. Итак, в данном примере мы
наблюдали, как релейный почтовый сервер доставляет почту в «чужой»
удаленный домен, используя разрешение имени типа MX в системе имен DNS.
При этом письмо появляется в папке Queue когда поступает на сервер и
исчезает оттуда, когда передается MX целевого домена.
Рассмотрим следующий пример, предположим, мы конфигурируем
релейный сервер не провайдера, а офисный сервер. В таком случае, как мы