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

Чем больше я работаю с почтой, тем виднее становится причина такого количества проблем: отсутствие унификации. Отсутствие от слова "совсем". Многие возразят словами "протокол SMTP нужен, и он унифицирован" на что я отвечу, что дело не в протоколе SMTP, ибо он обеспечивает только передачу данных, но не обеспечивает дополнительных сервисов. Это как азбука морзе или бинарный код: с их помощью можно передать что угодно, даже картинку и видео, вопрос только во времени, удобстве, и количестве надстроек.

Но дело ведь не в передаче данных. Данные нужно хранить, данные нужно передавать, данные нужно обрабатывать, и существование трех протоколов (с их количеством безопасных и не очень портов) только для обмена данными - это чересчур как по мне. Чтобы вам было понятно, приведу пример: настройте мне систему, которая позволит мне читать почту, которую мне будут слать клиенты. При чем я не хочу пользоваться Outlook'ом и прочими клиентами, равно как не хочу пользоваться всякими Squirelmail или Roundcube. Я хочу просто читать свою почту. И отсылать ее. На настройку такой системы вы убьете ЧАС как минимум, и это если будете пользоваться настройками из коробки, установленными через apt-get/yum. А если после того как вы мне это сделаете, я попрошу добавить туда еще одного пользователя, из другого домена - вы убьете на это еще один час. И вряд ли сделаете.

Поэтому почтовая система нуждается в тотальной переработке. Устаревшие pop,smtp,imap давно себя изжили! А мякотка в том, что и придумывать-то ничего не нужно, нужно всего лишь отдать почту вебу.

В самом деле, что может быть проще, имея веб-сервер со своей веб-директорией для домена, иметь в ней еще и секретную папку ".mail" где будет храниться почта, которую туда сможет записать каждый (при наличии определенных условий, конечно), которая будет храниться в виде текстовых файлов, или даже HTML, доступ к которой сможет получить любое ваше приложение, а при наличии системы авторизации - извне тоже ?

Обмен информацией будет вестись при помощи всего лишь одного протокола - HTTP, который прост в семантике, универсален, существует на любом устройстве, и может обрабатываться даже скриптом на баше. Да, почтовая система на баше, вы правильно поняли.

Итак, плюсы возможного перевода почты на HTTP:

1. Простота установки. Для работы почтовой системы понадобится всего лишь веб-сервер, который и так устанавливается.

2. Простота обмена информацией. Для отсылки письма нужно всего лишь передать серверу POST-запрос, в котором будет просьба записи письма, необходимые реквизиты, само письмо, имя аккаунта, и вообще все что мы только захотим. Неизвестные параметры просто отсекутся.

3. Отсутствие необходимости настраивать несколько разных систем - релеев, серверов хранений, серверов отсылки, авторизаций, проверок на отправку, проверок на прием, DKIM, SPF, отдельные MX, и многого другого. Клиент (а это может быть браузер, отдельный клиент, скрипт, или кто угодно) просто передает домену адресата команду "отправляю вам письмо".

4. Следствие из третьего пункта - меньший шанс чему-то поломаться, вследствие чего сократится трата времени на настройку и фиксы.

5. Относительно легкий доступ к почте с возможностью ее просто прочитать, или скачать, или передать далее. Нет ничего проще текстовых или html файлов в определенной папке, читать которые можно каким угодно приложением.

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

7. Клиентам не придется извращаться, отправляя разного рода вложения в почту. Все вложения могут идти дополнительными файлами, главное письмо может содержать только ссылку-инклуд на них. Или вообще на внешний источник. Зачем ждать, пока вложение прикрепится, отошлется, потом ждать пока оно скачается, если вашему адресату его можно передать прямо с вашего компьютера ?

8. Простая система хранения. Все хранится в одной папке - .mail, которая лежит в корневой папке домена. Это все. Все письма и настройки, хранятся в этой папке, не придется больше шариться по конфигам sendmail, exim4, postfix, dovecot, привязывать базы данных MySQL, ковыряться с настройками доступа.

9. Вытекающая из предыдущего пункта возможность легкой миграции почты с одного сервера на другой. Заархивировал директорию на одном сервере, разархивировал на другом. Это все. Кстати не лишним было бы предусмотреть миграцию в самой реализации сервера, по типу кнопки "Добавить мою старую почту". Это удобно.

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

11. Поддержка плагинов. Нет ничего проще, чем разместить в папке .mail, ваш собственный скрипт, который будет обрабатывать почту так как вам нужно.

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

Проект стартовал

 Здесь я буду перечислять основные фичи. Черновик.

Авторизация при отправке письма

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

Давайте представим, что мы хотим отослать письмо с нашего адреса "admin@noname.com" на почту "vasya@microsoft.com". Процесс будет выглядеть так: a) Наш клиент авторизуется логином и паролем на сервере noname.com, при чем через обычный POST-запрос; б) Сервер noname.com генерирует токен, который сохраняет у себя в базе и отдает нашему клиенту; в) Наш клиент при помощи того же POST-запроса, шлет серверу microsoft.com письмо с текстом самого письма и токеном; г) Сервер microsoft.com отсылает серверу noname.com вопрос, создавал ли он такой токен, в случае положительного ответа, письмо сохраняется, в случае отрицательного - адресат помещается в спам-лист.

Реализация функционала авторизации на PHP (самом популярном языке) займет 10 строчек на каждом из серверов. Метод работы просто и понятен. Чем-то напоминает "подтверждение регистрации по почте". В обмене информацией используется один протокол HTTP, и три запроса, отправитель->сервер отправителя, отправитель->адресат, адресат->сервер отправителя. Все просто и понятно.

Статья будет периодически дополняться, так что добро пожаловать!

https://minidevices.top/images/ava.png

https://minidevices.top/images/ava.png

root

 29 апреля 2016 в 22:06 

♡  0  ♡

2660