Мне интересно, почему SMTP разработан таким образом, чтобы разрешить промежуточный MTA на пути сообщения. Согласно RFC 5321,
Цель простого протокола передачи почты (SMTP) - надежная и эффективная передача почты.
Хотя я не совсем понимаю, каковы здесь преимущества с точки зрения эффективности или надежности. Например, когда пользовательский агент отправляет сообщение в почтовую систему, насколько мне известно, нет гарантии, что сообщение наконец попадет в почтовый ящик назначения. Согласно RFC, упомянутому выше, MTA может ответить отправителю сообщением электронной почты об ошибке доставки (DSN). Однако сервер может также не доставить этот отчет об ошибке. Так о какой надежности говорит RFC? ИМО, гораздо более надежным подходом было бы подключение к конечному серверу и отправка сообщения напрямую. Если соединение не удалось, или сервер отклонил сообщение, отправитель точно знает, что доставка не удалась.
Я искал обоснование такой схемы транспортировки почты в SMTP RFC, в книге А. Таненбаума «Компьютерные сети» и во многих ресурсах в сети. Ни один из них не дал мне четкого представления о цели маршрутизации электронной почты. Однако я могу придумать следующие объяснения:
1) Меньше соединений, необходимых для отправки сообщений. Представьте, что мы находимся в сети компании с собственным MTA, работающим в качестве ретранслятора. Многие люди могут отправлять сообщения, например, на SMTP-сервер gmail.com. Если все будут подключаться к gmail.com напрямую, количество подключений на сервере вырастет. Вместо этого сервер ретрансляции нашей компании может открыть одно TCP-соединение с gmail.com и передать все сообщения через одно соединение. Таким образом снижается нагрузка на целевой сервер.
2) На промежуточном MTA может быть настроен некоторый контроль трафика / антиспама, что также снижает нагрузку на целевой сервер.
3) В случае нескольких пунктов назначения для дедупликации сообщений можно использовать несколько промежуточных MTA. Например, один экземпляр сообщения передается на top.com, затем он разделяется на два сервера mid1.top.com и mid2.top.com и так далее. В противном случае нам пришлось бы открывать отдельные TCP-соединения для каждого пункта назначения и копировать сообщение в каждый из них.
Все вышесказанное - мое предположение. Вопрос в том, правда ли это, и есть ли какие-либо другие причины маршрутизации электронной почты в структуре SMTP.
Обычный вариант использования: если целевой пункт назначения временно отключен, отправитель может попытаться доставить на промежуточный хост (обычно поставщик услуг целевого пункта назначения) с более высоким номером записи MX. Промежуточный хост будет периодически пытаться доставить сообщения, и когда целевой хост-адресат возвращается в оперативный режим, сообщения доставляются.
"Надежный" в этом контексте просто означает "не теряйте и не отбрасывайте сообщение без попытка уведомить отправителя ". Конечно, с приложением или очередью сообщений, которые ты контролируешь, это нормально - сразу узнавать об ошибках (быстро сбой). И другие заметили здесь ранее, что постановка SMTP-сообщений в очередь на промежуточных узлах может привести к нежелательным результатам, потому что через несколько дней вы часто узнаете, что сообщение не было доставлено. Но это та система, которая у нас есть, и решение о том, как долго сообщение должно быть поставлено в очередь, зависит от принимающей системы и посредников, которых они выбирают, а не от отправителя.
Вы правы в пункте 2, такие сервисы, как MessageLabs, делают именно это. Если нежелательные или вредоносные программы могут быть перехвачены до того, как они прибудут в пункт назначения, для пункта назначения это будет меньше работы. В этом сценарии промежуточный хост будет иметь номер записи MX ниже фактического целевого объекта.