Когда статические файлы извлекаются во время SMTP?
Алиса отправляет Бобу сообщение электронной почты. Он каким-то образом включает в себя большой статический контент. Исходя из моего самого базового понимания электронной почты, вы можете просто отправить сообщение HTML, поэтому предположим, что HTML включает тег изображения . 
- Почтовый пользовательский агент Алисы отправляет сообщение ее агенту пересылки почты (MTA)
- Ее MTA пересылает его через некоторые другие MTA (?)
- Он прибывает в MTA назначения.
- MTA назначения передает сообщение агенту доставки почты, который может связаться с Бобом.
- Агент пользователя почты Боба заберет сообщение при следующем запуске.
Что такое происходит с большим статическим файлом, когда сообщение отправляется от Алисы к Бобу?
Сохраняет ли MDA назначения сам файл и становится ли он новым хостом этого изображения? Например. переписать HTML на src = "destinationMDA.com/assets/x123x1nj4xn1i4.jpg"
Или статический файл все еще размещен на dogpics.com и будет получен только тогда, когда Боб откроет свой MUA и читает сообщение?
Но это также похоже на то, что тело сообщения может быть составным MIME-типом . Зависит ли то, где изображение загружается в первую очередь, от того, встроенное ли это изображение или вложение к электронному письму (которые, я думаю, могут использовать типы MIME?)
Да, это зависит от того, как было упомянуто изображение.
Вы можете поместить изображение в сообщение в формате MIME и указать его с помощью cid: , как описано в RFC 2392 . Затем изображение передается вместе с остальной частью сообщения, и каждый, кто обработал сообщение, также может получить прямой доступ к изображению без дальнейшего извлечения - это часть сообщения, если никто не удаляет вложение.
Для писем с одной частью html встраивание изображения прямо в data: URI работает аналогично, но невидимо для MUA, не отображающих части html.
Вы также можете связать изображение для последующего извлечения и ссылаться на него с помощью общего протокола, используемого MUA, обычно https: .
Затем изображение может быть получено индивидуально каждым программным обеспечением, обрабатывающим почту - и, в зависимости от конфигурации получателя, да, электронное письмо может быть изменено, чтобы ссылаться на кешированную версию внешнего ресурса вместо URL-адреса, предоставленного отправителем. Обычно MTA-получатель загружает изображение, проверяет его на предмет несоответствующего содержимого (не является ли это вымогателем ) и переписывает письмо, чтобы оно больше не содержало никаких внешних ссылок.
Если сообщение не переписывается и получатели MUA настроен на выборку внешних ресурсов, загрузка может даже произойти сразу же, когда сообщение открывается получателем (и, возможно, несколько раз в более поздних случаях, если не кэшируется). Этот простой подход был обычным явлением, но, поскольку он часто использовался для уведомления отправителя о том, когда, как часто и откуда извлекались внешние ресурсы, он больше не является типичным (воспринимайте его как непроизвольные уведомления о прочтении).
Здесь есть два разных случая: один относится к некоторому носителю (изображение собаки) из тела сообщения HTML, а другой отправляет некоторый кусок данных с сообщением в форма вложения.
В первом случае SMTP - и фактически любые другие задействованные протоколы, такие как IMAP, POP3, LMTP - совершенно не заботятся об изображении. MUA получателя полностью определяет смысл тела сообщения, что означает, что он пытается отобразить HTML и при этом извлекает изображение с помощью HTTP, как это сделал бы любой веб-браузер.
Во втором случае отправитель прикрепляет изображение собаки, которое он / она хранит на своей локальной машине, непосредственно к сообщению. Это формирует составное сообщение, в котором двоичные данные этого изображения кодируются в некоторой текстовой форме (обычно base64 или так называемая цитируемая печать) и помещаются где-то в теле сообщения. Дополнительную информацию об этом можно найти в RFC 2045 и в четырех следующих RFC. Если ваш MUA имеет некоторую функцию «сохранить сообщение как ...», он, скорее всего, сохранит сообщение в формате eml, что на самом деле является именно тем, что описывает вышеупомянутый RFC. Это может дать вам некоторое представление, если вы создадите, затем сохраните эти сообщения, а затем откроете их в своем любимом текстовом редакторе.