Почему почтовые клиенты не используют напрямую SMTP-сервер получателя

Question

Обычно в почтовом клиенте вам нужно настроить SMTP-сервер для отправки почты. Когда вы отправляете почту, ваш настроенный SMTP-сервер просто разрешает домен после @at в адресе электронной почты получателя с запросом DNS типа MX. DNS ответит адресом SMTP-сервера почтового обменника почтового провайдера получателя, и ваш SMTP-сервер перенаправит вашу почту на него.

Мой вопрос: почему это не делается напрямую почтовым клиентом? В этом нет ничего особенного: это всего лишь DNS-запрос mx, и протокол работает непосредственно с почтовым обменником поставщика получателя всегда SMTP.

Если бы это было так, почта могла бы отправляться прямо на нужный сервер: она должна быть быстрее и избегать бесполезного трафика.

Может быть, это связано с тем, что, возможно, SMTP-сервер получателя по какой-то причине не работает или слишком занят для обработки почты при ее отправке, и поэтому преимущество использования нашего личного SMTP-сервера заключается в том, что он пытается повторить попытку отправлять почту через равные промежутки времени?

Это единственная причина, которую я вижу: на самом деле было бы не очень практично, если бы это было ответственностью почтового клиента, так как, возможно, пользователь закрыл его или выключил компьютер.

Если это единственная причина: случается ли так часто, что SMTP-сервер не может немедленно обработать электронную почту?

Answer 1

Одна из возможных причин заключается в том, что отправитель может просто не иметь возможности напрямую связаться с почтовым сервером получателя.

В первые дни электронной почты и SMTP у вас было больше, чем просто Интернет - у вас был Bitnet; UUCPnet/Usenet; Berknet; MILNET; DECnet; и т. д. все используют несовместимые протоколы. Домен, подобный sri-unix.uucp мог не иметь IP-адреса в DNS - только запись MX, указывающая на шлюз (SMTP-сервер, который также имел ссылки UUCP).

В наши дни похожая ситуация наблюдается при обмене данными между хостами, использующими только IPv4 и только IPv6 (хотя последние встречаются довольно редко).

Кроме того, сети были не совсем надежными (и до сих пор нет) - вы бы не хотели смотреть на «почтовый сервер получателя недоступен, пожалуйста, подождите» в течение получаса, когда вы могли бы просто передать сообщение sendmail работает 24/7 на том же компьютере, на котором вы писали сообщение, и продолжайте работу.

---

Бонус: некоторые действительно странные адреса «От:», которые я видел на OldUse.Net:

• UCBVAX.@MIT-MC.@rand-relay.ARPA.goldfarb.UCF-CS@RAND-RELAY

• farber%udel-eecis1.udeecis@udel-ee@sri-unix.UUCP

• notes@CSvax:Pucc-H:pur-phy.UUCP

• utzoo!linus!security!genrad!decvax!harpo!floyd!whuxlb!pyuxll!abnjh!u1100a!pyuxn!pyuxi!mhuxm!mhuxd!mhuxa!houxm!hocda!spanky!burl!akgua!emory!sb6!sb1!ll1!otuxa!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!mcewan

Answer 2

Если это единственная причина: случается ли так часто, что SMTP-сервер не может немедленно обработать электронную почту?

Это происходит, особенно когда SMTP-сервер обслуживается небольшой организацией.

Но помимо того, что он действительно не может обрабатывать входящую почту, иногда он может, но не хочет. Два примера, которые приходят на ум:

1. Серверы, которые используют серый список, отклоняют первые попытки неизвестных отправителей с ошибками 4xx систематически, нарочно, как метод против спамеров.

2. Некоторые почтовые провайдеры используют регулирование против своих собственных клиентов, отвечая ошибками 4xx, когда слишком много писем отправляется за единицу времени с одного и того же IP-адреса или учетной записи. Это может помешать клиенту спамить, умышленно (малый бизнес отправляет свой информационный бюллетень) или нет (как жертва инфекции). Недавно я видел, как GMail делает это даже не за сотню сообщений в день, а с платного аккаунта, когда сообщение SMTP ... почта, отправленная с вашего IP-адреса, была временно ограничена ...

Существует также случай временного сбоя DNS для целевого MX.

Более практично иметь первый SMTP-прыжок, чтобы справиться со всем этим, а не оставлять его почтовому клиенту.

Answer 3

drk.com.ar в комментариях это правильно.

Если у вас есть статический IP-адрес от вашего интернет-провайдера, вы можете разместить свой собственный SMTP локально, как вам нравится, и иметь эту обрабатывающую почту, это нормально. Тогда, если вы злоупотребите им, spamhause и co внесут вас в черный список, и вы будете полностью проигнорированы.

С динамическими IP-адресами это не работает, они не могут блокировать ваш IP-адрес, так как вы можете изменить его в течение 60 секунд или около того. Поэтому в этом случае ваш интернет-провайдер несет ответственность за фильтрацию исходящей почты. Вы пересылаете всю почту на их SMTP-сервер, который затем направляет ее, и если вы начнете злоупотреблять ею, их записи об аренде будут точно знать, откуда она поступила, и могут соответствующим образом отреагировать.

Интересно, что у нас была проблема с этим несколько месяцев назад, когда наша родительская компания-провайдер, провайдер Cello, не управляла своим SMTP-сервером должным образом, и некоторые кластеры блокировались как спамеры, что приводило к прерывистым спамблокам на принимающей стороне.

Надеюсь это поможет.

Answer 4

Фактический сервер может быть недоступен. Итак, вам нужен ваш сервер для повторной попытки.

Вот почему иногда вы получаете «Это письмо не дошло до получателя. Повторим в ближайшее время. С этим ничего не нужно делать ".

И в итоге вы получаете "Не дошёл до получателя". Эта неудача необратима ».