В   первых   трех   пакетах   клиент   (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 целевого домена.

Рассмотрим   следующий   пример,   предположим,   мы   конфигурируем 

релейный  сервер  не  провайдера,   а  офисный  сервер.   В  таком   случае,  как   мы