который   затем   распределяет   полученную   почту   между   почтовыми   ящиками 
пользователей в офисе. В чем недостаток такого подхода? Очевидно, что письма 
в домен могут поступать в произвольное время, но так как MX домена доступен в 
Интернет не всегда, то почтовые сервера, получая письма для данного домена, 
часто не смогут передать эти письма почтовому серверу компании немедленно 
(так   как   он   не   доступен),   после   чего   отложат   попытки   доставить   письма, 
повторяя их через некоторые интервалы времени, но при этом не существует 
никакой гарантии, что в момент, когда удаленный почтовый сервер предпримет 
очередную попытку передать письмо в данный домен,  MX  этого домена будет 
работать.   Это   в   конечном   итоге   приведет   к   потере   писем,   к   значительным 
задержкам доставки тех писем, которые не потеряются (все зависит от того, как 
часто  MX  доступен   в   Интернет   и   как   много   писем   он   должен   получать  ). 

Разумеется, такое решение не может считаться приемлемым, необходимо искать 
другой выход. Альтернативным решением для данной компании было бы указать 
в   своей   базе  DNS  в   качестве  MX,   почтовый   сервер   своего   провайдера   (или 
другой   компании,   которая   предоставит   данную   услугу),   тогда   такой   сервер 
всегда   будет   доступен   в   Интернет.   В   таком   случае,   естественным   развитием 
такого   решения   является   организация   полноценного   почтового   сервера   с 
почтовыми ящиками пользователей на площадке провайдера. Но это может быть 
не удобно, так как такой сервер компании будет не удобно администрировать 
(создавать и удалять пользователей и списки рассылки и т.д.), и управлять его 
производительностью (например, выделять дисковое пространство для ящиков 
пользователей,   так   как   сервер   принадлежит   провайдеру   и   провайдер   станет 
накладывать ограничения на ресурсы, выделяемые данному клиенту). Решением 
проблемы   могло   бы   стать   размещение   собственного   сервера   на   площадке 
провайдера, однако такое решение будет весьма дорогим. 

Расширение

 SMTP,   которое   мы   рассмотрим,   призвано   решить 

вышеописанную задачу максимально эффективно и просто. Данное расширение 
называется    Remote  Queue  Processing  Declaration.   Сервер,   поддерживающий 
данное расширение сообщает в отклике на команду EHLO ключевое слово ETRN 
(Enhanced TURN), видно, что сервер MS IIS поддерживает данное расширение.