Drafts в почте что это

Если к письму были прикреплены файлы, то в оглавлении в поле Тема выводится символ +. Список файлов приводится в разделе Вставки. Щелчок левой кнопкой мыши по имени файла инициирует диалог для сохранения этого файла на диске.

ЗАДАНИЕ. Прочитать присланное вам преподавателем письмо. Ответить отправителю. Следует учесть, что преподаватель узнает ваш электронный адрес только после того, как вы пошлете ему письмо.

ЗАДАНИЕ. Просмотреть содержимое всех папок и очистить почтовый ящик от ненужной корреспонденции.

Источник

IMAP и POP Gmail через telnet или читать почту это просто

Я решил написать эту статью после того, как мне потребовалось написать простенький почтовик, который будет обслуживать почту из Gmail. Надеюсь, что кому-то стало проще жить — хоть в целом это выглядит как пособие от Капитана Очевидность 🙂 Всю необходимую для написания клиента информацию я нашёл в гугле минут за 10 — но считаю, что простенький мануал типа такого — хорошая шпаргалка на будущее 🙂

В этом нет ничего сложного — правда! Фактически — написать свой почтовик — проще простого. Так же просто как и читать почту через консоль.

Далее — две маленькие статьи на живых примерах — как пользоваться POP3 и IMAP без почтового клиента.

Читаем POP3

Вам потребуется Linux. Ну или поддержка OpenSSL в Windows — если она у вас есть — то, вероятно, статья не для вас — вы и так всё знаете 🙂

Далее — набор команд с расшифровкой:

В случае успешного соединения мы видим что-то типа следующего:

CONNECTED(00000003)
. куча букв и цифр, свидетельствующих о SSL…
+OK Gpop ready for requests from 79.165.189.32 3pf3718132bwz.16

Это значит что на первом этапе всё прошло отлично и мы присоединились к почтовику Гугла.
Далее нам следует авторизоваться.

В случае успешного прохождения команды мы видим строчку:

Нас просят ввести пароль. Что мы и сделаем:

В случае если пароль верен — нас пускают внутрь!

Вот мы и внутри нашего почтового ящика.
Давайте проверим — пришли ли нам новые сообщения?

Я увидел следующее:

Это значит, что на сервере у меня 15 непрочитанных писем общим размером 1 408 449 байт.

Интересно — а сколько весит каждое непрочитанное письмо?

Вот и список сообщений:

+OK 15 messages (1408449 bytes)
1 3423
2 42610
3 3693
4 3693
5 445122
6 1933
7 3488
8 3760
9 3155
10 439325
11 9071
12 3125
13 3575
14 3997
15 438479

Видите — пока ничего сложного 🙂

Давайте прочитаем пятое сообщение — что-то в нём много байт — наверное, интересное письмо!

Для чтения письма доступна команда TOP

Этой командой мы запросили пятое письмо без его текста — получить только заголовки. В заголовках, помимо всего прочего, отбражается кому пришло это письмо, от кого и какая у письма тема.

…
From: root
To: master@skazkin.ru
Subject: Cron perl /home/common/parser.pl queue
…

Мне пришёл отчёт с моего сервера — что парсер закончил строить очередь. Хорошо, читать мне это не очень интересно — там разная служебная информация.
Пометим его для удаления

Гмейл удалит отмеченные для удаления письма после выхода из системы.

Прочитаем самое маленькое письмо —

Subject: =?KOI8-R?B?0NLJ18XU?=
From: =?KOI8-R?B?4c7Uz84g58HCz9c=?=
To: Andrew Skazkin
Content-Type: text/plain; charset=ISO-8859-1

Ого — не читается 🙁
Это уже решается почтовыми клиентами — тема письма — в кодировке KOI8-R и зашифрована BASE64.

Чтож, почта прочитана и пора выходить.

Я так подумал — не буду я удалять письмо от Cron.

Эта команда сбрасывает флажки на удаление у писем, которые мы отметили для удаления.

Такой ответ — в случае успеха. Теперь можно выйти.

Вот и всё. С POP3 мы разобрались, не так ли? Пришла пора для IMAP.

Играемся с IMAP

Процедура мало чем отличается — только лишь командами.

Опять выдала нам кучу букв и цифр, и последняя строчка —

+OK Gpop ready for requests from 79.165.189.32 1pf4035116fxm.33

* CAPABILITY IMAP4rev1 UNSELECT LITERAL+ IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE
. OK я gmail.com authenticated (Success)

Обратите внимание — все команды предваряются точкой и пробелом!

Получим список наших папок в аккаунте:

Нам вываливается список папок:

* LIST (\HasNoChildren) «/» «Cron»
* LIST (\HasNoChildren) «/» «INBOX»
* LIST (\HasNoChildren) «/» «LJ»
* LIST (\HasNoChildren) «/» «Proxies»
* LIST (\HasNoChildren) «/» «WordPress»
* LIST (\Noselect \HasChildren) «/» «[Gmail]»
* LIST (\HasNoChildren) «/» «[Gmail]/&BBIEQQRP- &BD8EPgRHBEIEMA-»
* LIST (\HasNoChildren) «/» «[Gmail]/&BBoEPgRABDcEOAQ9BDA-»
* LIST (\HasNoChildren) «/» «[Gmail]/&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-»
* LIST (\HasNoChildren) «/» «[Gmail]/&BB8EPgQ8BDUERwQ1BD0EPQRLBDU-»
* LIST (\HasNoChildren) «/» «[Gmail]/&BCEEPwQwBDw-»
* LIST (\HasNoChildren) «/» «[Gmail]/&BCcENQRABD0EPgQyBDgEOgQ4-»
. OK Success

То, что с непонятными символами — папки, названные по-русски.

Сколько у нас писем в папке INBOX?

Ого! Есть новая почта! Почитаем её:

* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* OK [UIDVALIDITY 2]
* 8 EXISTS
* 0 RECENT
* OK [UIDNEXT 68967]
. OK [READ-WRITE] inbox selected. (Success)

Посмотрим — что из восьми писем ещё не прочитано:

Эта команда выбирает флаги для всех писем, начиная с первого.

* 1 FETCH (FLAGS (\Seen))
* 2 FETCH (FLAGS (\Seen))
* 3 FETCH (FLAGS (\Seen))
* 4 FETCH (FLAGS (\Seen))
* 5 FETCH (FLAGS (\Seen))
* 6 FETCH (FLAGS ())
* 7 FETCH (FLAGS ())
* 8 FETCH (FLAGS ())
. OK Success

Прочитаем седьмое письмо — его заголовки

* 7 FETCH (ENVELOPE («Fri, 20 Nov 2009 09:58:35 +0000» «=?KOI8-R?B?79TXxdTJ1NggzsEg08/Pwt3FzsnFICfSwcLP1MXOy8EgzsEgMSDCwcvTJw==?=» ((«=?KOI8-R?B?5s/S1c0gzyDQz8nTy8/X2cgg08nT1MXNwcg=?=» NIL «root» «searchengines.ru»)) ((«=?KOI8-R?B?5s/S1c0gzyDQz8nTy8/X2cgg08nT1MXNwcg=?=» NIL «root» «searchengines.ru»)) ((«=?KOI8-R?B?5s/S1c0gzyDQz8nTy8/X2cgg08nT1MXNwcg=?=» NIL «root» «searchengines.ru»)) ((NIL NIL «master» «skazkin.ru»)) NIL NIL NIL » «) FLAGS () INTERNALDATE «20-Nov-2009 09:58:38 +0000» RFC822.SIZE 4045)
. OK Success

В целом конечно понятно — но хотелось бы ещё понятнее

. fetch 7 (body[header.fields (from to subject date)])

Выбираем только интересные заголовки:

* 7 FETCH (BODY[HEADER.FIELDS (from to subject date)] <334>
Date: Fri, 20 Nov 2009 09:58:35 +0000
To: master@skazkin.ru
From: =?windows-1251?q?=D4=EE=F0=F3=EC_=EE_=EF=EE=E8=F1=EA=EE=E2=FB=F5_=F1=E8=F1=F2=E5=EC=E0=F5?=

Subject: =?windows-1251?q?=CE=F2=E2=E5=F2=E8=F2=FC_=ED=E0_=F1=EE=EE=E1=F9=E5=ED=E8=E5_=27=F0=E0=E1=EE=F2=E5=ED=EA=E0_=ED=E0_1_=E1=E0=EA=F1=27?=

Прочитаем тело письма:

* 7 FETCH (RFC822.TEXT <1299>
… сообщение в кодировке windows-1251
. OK Success

В целом, как видите, нет ничего сложного чтобы управляться с консольными выводами POP3 и IMAP.

Разница только в том, что IMAP — понавороченнее, а POP3 обладает весьма урезанным функционалом — и позволяет читать только почту, которая лежит в папке INBOX.

Источник

Draft — почему стоит настаивать на своем варианте

Каждый стартап, как и любой бизнес, сталкивается с подписанием контрактов/договоров. На первом этапе это договора аренды офиса, первые трудовые договора и т.д. Со временем этом ком растет, а папки в кабинете у юриста увеличиваются в алгебраической прогрессии. И тут не важно, продуктовая эта компания или аутсорсинговая, контрактов будет все больше.

Я юрист, который в душе IT, поэтому основные мои места работы — это IT компании, как лидеры рынка, так и молодые компании, но во всех я придерживался одного правила, всегда настаивать на подписании своего драфт- контракта.

О необходимости разработки Contract case я расскажу отдельно, это большая тема для обсуждения, как, впрочем, и привлечение юриста в штат компании. В этой статье я хочу поговорить именно о подписании своих проектов договоров.

Для начала, надо понимать какие юридические моменты нас ожидают и что такое draft с точки зрения законодателей.

Действующее законодательство Украины и России не регламентирует обязанность определенной стороны на создание проекта договора. Таким образом, каждый волен предоставить свой вариант. Обычно, по практике классического бизнеса, свой проект договора предоставляет исполнитель, а заказчик уже вносит свои правки.

В IT все немного не так. Преимущественно договор предоставляет тот, кто платит. Крупные компании уже давно подписывают только свои варианты, исключения составляют разве что договора с банками, но и тут не все так просто – эти динозавры ещё не научились реагировать на современный рынок и отказываются понимать, что на дворе уже XXI век и надо быть мобильными и актуальными.

Придя в новый стартап, я всегда начинаю с того, что разрабатываю Сontract box, куда включаю наиболее потенциально возможные договора. Это очень экономит время в будущем, когда необходимо заключать контракт, ты не тратишь дополнительные часы на его разработку, а как показывает опыт, в начале пути, у юриста дел не так уж много, поэтому необходимо самоорганизовываться.

Данный принцип хорошо работает в аутсорсинге, но как предположить какие будут договора у продуктовой компании? Это отдельная история — тут важно, чтобы юрист понимал процессы работы в такой компании и представлял себе конечный продукт, а также имел и юридический опыт. Отдельно эту тему в будущем мы тоже раскроем.

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

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

Draft – как часть корпоративной культуры

Любая уважающая себя компания имеет свои корпоративные стандарты и культуру. Культура договоров и оформления документов это неотъемлемая их часть. Она совсем не главная, но тем не менее крайне важная. К примеру, вы оказываете работы по разработке приложения и первое с чем столкнутся ваши клиенты, начиная работать с вами – это ваши проекты договоров. По сути, это первое впечатление о вас, не считая вылизанного портфолио и сайта, как вы относитесь к своим обязанностям и самое главное мелочам. И очень сомнивательно, что вы как юрист вызовите у руководителя уважение к себе, если на подпись вы предоставите обычный шаблон документа скаченный по первой ссылке в гугле и наспех доработанный менеджером.

В Formula 1, есть поговорка, «только красивая машина может быть быстрой». Тоже самое и с контрактом. Только красивый и продуманный договор может дополнить уверенность клиента в том, что вы профессионален и ответственно относитесь к своей работе и мелочам.

Пренебрежительное отношение к оформлению проекта контракта является первым признаком, что и к основной работе в компании вы также относитесь. Конечно, чувство красоты наверное одно из самых субъективных. Буквально недавно у меня был спор, о том, каким шрифтом писать документ (который так и не закончился).

Казалось бы, мелочь и это не стоит даже внимания, но именно такое отношение к мельчайшим деталям и показывает отношения к работе в целом. И далеко за примером ходить не надо, гений Стив Джобс прорабатывал каждую деталь включая расположение элементов на плате в продуктах компании Apple, которую никогда не должен был увидеть пользователь. Однако такой перфекционизм прослеживается
всюду в их продукции и как результат в финансовых показателях.

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

Источник

Internet Message Access Protocol (imap) — протокол доступа к почте

Первая версия появилась в 1986 году, тогда протокол расшифровывался, как Interim Mail Access Protocol. Вторая версия вышла в 1988 году, название протокола было изменено на Interactive Mail Access Protocol. В 1991 году появилась третья версия, и в 1994 году четвертая версия протокола IMAP4, которую мы используем до сих пор. Спецификация чертой версии протокола IMAP была обновлена в 2003 году, после этого вышли дополнительные расширения протокола IMAP4.

Архитектура электронной почты

Протокол IMAP, также как и протокол РОР3 используется для чтения электронной почты, которая уже пришла в почтовый ящик пользователя. Для передачи почты используется протокол SMTP, а не IMAP.

Протокол IMAP

В отличие от протокола РОР3 в котором почтовые клиенты загружают все письма к себе и сразу их удаляют с сервера, в протоколе IMAP письма постоянно сохраняются на сервере. Клиенты загружают не все письма сразу а только те, которые пользователи явно запросил, кроме этого есть возможность синхронизации, при которой почтовый клиент, переписывает все письма с сервера но не удаляет их. IMAP сервер в отличие от РОР3 сервера, может выполнять с письмами вполне сложные действия, например выполнять поиск писем по заданному шаблону.

Преимущества протокола IMAP заключается в том, что с почтовым ящиком может одновременно работать несколько клиентов, и это соответствует современной модели работы с электронной почтой. У нас у всех есть несколько устройств, некоторые из них мобильные и мы хотим видеть единое состояние почтового ящика с помощью всех этих устройств.

С другой стороны, для того чтобы это обеспечить требуется протокол гораздо более сложный, чем РОР3. Повышенная сложность является существенным недостатком протокола IMAP. Другой недостаток заключается в том, что дисковая пространство на сервере, как правило ограничено, таким образом приходиться удалять письма из почтового ящика, чтобы он не переполнился.

Место в стеке TCP/IP

В стеке протоколов TCP/IP протокол IMAP находится на прикладном уровне.

IMAP использует протокол транспортного уровня TCP. Сервер IMAP работает на 143 порту.

Папки (mailbox)

В отличие от протокола РОР3, протокол IMAP позволяет использовать несколько почтовых ящиков (mailbox) или по-русски папки.

Папки хранятся на сервере, они могут быть вложены в друг друга и письма можно перемещать между разными папками.

В протоколе РОР3 создания папок и фильтрация сообщений используется локально с помощью почтовых клиентов. В IMAP есть папка специального типа INBOX, это почтовый ящик пользователя по умолчанию, именно туда записываются все входящие письма. Затем можно выполнять их сортировку с помощью почтовых клиентов, либо с помощью специальных программ.

Флаги

Другое отличие протокола IMAP от РОР3, это использование флагов. Именно благодаря флагам, протокол IMAP позволяет узнать прочитанное это сообщение или нет, а также много другой полезной информации.

Флаги в IMAP это небольшая метка (token) которая добавляется к письму. Письмо может иметь несколько меток или не иметь ни одной. Флаги в IMAP бывают двух типов: Системные и Пользовательские.

Системные флаги и их назначения заданы в стандарте IMAP и они начинаются с обратного слеша (\).

Также могут создаваться Пользовательские флаги. Они не могут начинаться с символа \.

Состояния сеанса IMAP

При работе по протоколу IMAP клиент проходит через четыре состояния.

Протокол IMAP, также как и другие почтовые протоколы работают в текстовом режиме и использует взаимодействие запрос-ответ. Однако существенным отличием является то, что IMAP позволяет выполнять одновременно несколько команд. Некоторые команды IMAP могут работать достаточно долго, например, поиск какого-то письма в большом почтовом ящике, где много писем, массовое обновление писем или другие подобные операции. Клиент может не дожидаться выполнения текущей команды, а запустить другую команду.

Для того чтобы отличать разные команды и ответы на них, в протоколе IMAP используются идентификаторы или теги команд. Это просто алфавитно-цифровая строка (А0001,А0002). Каждая команда клиента должна начинаться с тега. Сервер включает этот тег в ответ на команду, для того чтобы можно было определить к какой именно команде этот ответ относится.

Ответы IMAP

Ответ IMAP также как и других почтовых протоколов состоит из двух частей: Статус и Поясняющее сообщение.

В Статусе в ответов IMAP всего лишь три:

Пример сеанса IMAP

Команд в протоколе IMAP очень много, поэтому мы не будем перечислять их все.
Рассмотрим пример сеанса чтение писем. Подключаемся к серверу IMAP с использованием соединения TCP порт 143.

* OK Cyrus IMAP 4 server ready //сервер выдает сообщения со статусом ОК, сервер готов. Сеанс находится в состоянии preautentificated.

A0001 LOGIN username password // клиенту необходимо пройти аутентификацию, для этого используется команда LOGIN, в отличие от протокола РОР3 в команде LOGIN указываются одновременно имя пользователя и его пароль. Обратите внимание, что перед началом команды клиент указывает метку А0001

A0001 OK User logged in // в ответ сервер выдает сообщение тоже самой меткой, статус сообщения ОК команда выполнена успешна, поясняющее сообщение USER прошел аутентификацию.

Сейчас мы находимся в состоянии «аутентификация пройдена» и нам необходимо выбрать папку, с которой мы хотим работать.

A0002 LIST “” “*” // для того чтобы получить список всех папок используется команда LIST.

* LIST (\ HasChildren) “/” “INBOX” // Основная папка INBOX именно она считается основным почтовым ящиком пользователя и в нее доставляются все письма. В этой папке есть вложенные папки (\ HasChildren)

* LIST (\ HasChildren) “/” “INBOX/Drafts” // папка Draft черновики

* LIST (\ HasChildren) “/” “INBOX/Junk” // папка Junk спам

* LIST (\ HasChildren) “/” “INBOX/Sent” // папка Sent отправленные письма

* LIST (\ HasChildren) “/” “INBOX/Trash” //папка Trash корзина

A0002 OK Completed //завершается вывод ответом сервера ОК и номером метки А0002 указывающее, к какой команде относится ответ.

Выбор папки

Следующий этап сеанса IMAP это выбор папки из которой мы хотим читать письма.

A0003 SELECT INBOX //для этого используется команда SELECT, выбираем папку INBOX

* OK [UIDVALIDITY 1340776425]

A0003 OK [READ-WRITE] Completed

Просмотр списка писем

А0004 FETCH 1: * FLAGS // для того чтобы посмотреть какие сообщения есть на сервере используется команда FETCH ей необходимо указать номер письма, с которым мы хотим работать, либо диапазон через двоеточия. Диапазон от 1:* говорит от том, что мы хотим получить информацию обо всех письмах, затем указывается именно информацию мы хотим получить.

С начала мы хотим посмотреть флаги, в ответ сервер выдает перечень писем с флагами.

* 1 FETCH (FLAGS (\Seen)) // некоторые письма мы смотрели

* 2 FETCH (FLAGS (\Seen))

* 3 FETCH (FLAGS (\Answered \Seen)) // на некоторые мы отправили ответ

* 177 FETCH (FLAGS ()) // мы к нему подключались, но мы его не посмотрели.

* 178 FETCH (FLAGS (\Recent))

* 179 FETCH (FLAGS (\Recent)) // эти 3 письма мы видим в первый раз

* 180 FETCH (FLAGS (\Recent))

A0004 OK Completed (0.00 sec)

Чтение письма и установка флагов

A0005 FETICH 180 BODY [] // для того чтобы посмотреть письмо используется команда FETCH, указываем номер письма 180 последнее письмо, которое пришло, и что именно мы хотим посмотреть тело сообщения полностью BODY []

* 180 FETICH (FLAGS (\Recent \Seen) BODY [] <7077>//Сначала показываются флаги сообщения (FLAGS (\Recent \Seen), сервер автоматический установил у сообщения флаг Seen, означает то, что оно было просмотрено

Передача тела письма // а после этого выводиться само сообщение

Мы посмотрели сообщение или передали его на клиент, предположим, что мы решили, что в сообщение нет ничего интересного и его нужно удалить.

А0005 OK Completed (0.000 sec)

A0006 STORE 180 +FLAGS \Deleted // для этого необходимо установить флаг Deleted и это делается с помощью команды STORE, нужно указать номер сообщения 180, что именно мы хотим сохранить, хотим установить флаг +FLAGS и какой именно флаг хотим установить Deleted

* 180 FETICH (FLAGS (\Recent \Deleted \Seen)) // результат выполнение команды у сообщения номер 180 установлен флаг Deleted в дополнение к двум флагам, которые уже были установлены Recent и Seen

A0006 OK Completed

Удаление писем и выход

В IMAP также как в РОР3 сообщения не удаляются сразу после того, как они были помечены на удаление.

A0007 EXPUNGE // В IMAP для этого используется специальная команда EXPUNGE. После того как это команда запущена, из папки удаляются все сообщения, которые были помечены на удаление. Если не запустить эту команду, а просто разорвать соединение, то в отличие от протокола РОР3 сообщения удалены не будут.

A0007 OK Completed

A0008 LOGOUT //для разрыва соединений используется команда LOGOUT

* BYE LOGOUT received //сервер отвечает, что полученная команда LOGOUT говорит нам пока.

A0008 OK Completed //и выдает ответ ОК команда выполнена.

После этого соединение разрывается.

Другие команды IMAP

В протоколе IMAP имеется больше количество других команд.

Команда Перемещение писем:

С помощью команды SEARCH можно искать письма на сервере по требуемую шаблону.

Команда CLOSE выполняет закрытие папки, удаление в папке всех сообщений, которые помечены на удаление и переход в состояние authenticated. В этом состоянии клиент может выбрать другую папку и продолжить работу с ней.

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

Заключение

И так мы рассмотрели протокол IMAP. Он используется для чтения писем из почтового ящика пользователя.

Все письма хранятся на сервере, и с почтовым ящиком можно одновременно работать с нескольких устройств. Все эти устройства будут видеть согласованное состояние писем на сервере. Для отслеживание статуса сообщений в IMAP используются флаги, также в IMAP для удобства организации сообщений позволяет создавать на сервере папки.

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

Другой недостаток вызван тем, что все почтовые письма всех пользователей хранятся на сервере, если пользователей много, то серверу требуется большое количество дискового пространства. Однако сейчас, когда жесткие диски стали большими и относительно дешевыми, это уже не является такой большой проблемой.

Источник