Положение MIME в сетевом стеке

На основании того, что я нашел в Интернете, MIME (многоцелевые расширения почты Интернета, теперь Internet Media Type (?)) является способ описания типов файлов (заголовок, используемый несколькими протоколами).

Итак, MIME сам по себе не протокол, а расширение, используемое другими протоколами, верно?

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

Итак, если я отправляю письмо с вложением в формате mp3, SMTP / другой протокол прикладного уровня распознает, что это вложение в формате MP3, или это обязанность приложения исключительно распознать файл? В этом смысле MIME нельзя назвать расширением SMTP, а скорее функцией, которая будет использоваться приложениями.

Если SMTP не распознает, что это файл другого типа, как он будет правильно хранить его на почтовом сервере? (например, видеофайл MPEG требует хранения определенного формата, как почтовый сервер будет хранить его, не обрабатывая его?)

Извините, если мои вопросы звучат немного расплывчато, но я хочу понять, как разные протоколы (особенно SMTP) используют MIME.

Спасибо за вашу помощь.


browser email smtp
person Novak007    schedule 23.02.2015    source источник
comment
Вы были бы очень просветлены, если бы отправили себе короткое видео по электронной почте и изучили источник входящего сообщения.   -  person tripleee    schedule 01.03.2015

Ответы (2)


arrow_upward
1
arrow_downward

Электронная почта RFC 822 изначально была чисто текстовой, 7-битной US-ASCII. MIME определяет возможность инкапсуляции других типов носителей в почтовые контейнеры. Он не указывает никаких изменений в SMTP (хотя, например, расширение 8BITMIME ESMTP полезно для упрощения транспортировки сообщений MIME). Таким образом, это расширение существующего протокола, а не отдельный протокол. Это также демонстрируется тем фактом, что другие протоколы, в частности HTTP, включают (частично) MIME для тегирования типов контента и кодировок.

Тип Интернет-носителя - это только один аспект того, что MIME используется для кодификации; механизмы для определения наборов символов и кодировок все еще определены в собственно MIME.

Традиционно почтовый сервер просто хранит чистое сообщение RFC822 в своем хранилище сообщений; почтовый клиент несет ответственность за анализ и, возможно, манипулирование любой структурой MIME в теле для отображения и взаимодействия. (Тот факт, что RFC 822 был заменен на 2282, а затем на 5322, принципиально не изменил фактический формат почтового сообщения.)

Некоторые серверы отклоняются от этой модели; например, Microsoft Exchange, кажется, анализирует все входящие сообщения, чтобы преобразовать их в свой внутренний формат, в некоторой степени в ущерб его совместимости со стандартными инструментами и здравомыслию тех немногих из нас, кому требуется надежный, удачный доступ к нашей реальной электронной почте. .

person tripleee    schedule 01.03.2015

arrow_upward
1
arrow_downward

Сам протокол SMTP ничего не знает о формате MIME, но сам SMTP-сервер должен, по крайней мере, реализовать базовую поддержку rfc0822 для объявления заголовков Received, однако ему не нужно реализовывать MIME.

Как сервер сохраняет файл на диск? Таким же образом он получил его от клиента по потоку TCP / IP. Он просто сохраняет отправленные необработанные байты (с добавлением заголовка Received, о котором я упоминал).

Другими словами, вы слишком много думаете об этом. SMTP-серверу не нужно ничего знать о прикрепленных файлах mp3 или чем-либо еще, потому что формат MIME (это не протокол) - это просто способ сериализации данных mp3 в сообщении.

person jstedfast    schedule 01.03.2015