From: Андрей Великоредчанин <andrew at rodtext.ru>
Newsgroups: email
Date: Mon, 15 Sep 2004 14:31:37 +0000 (UTC)
Subject: NGMP - новый протокол передачи почты. Совместимый вариант (ngmp compatible).
Всем, думаю, хорошо извесна проблема спама. Решать ее пытаются самыми
разными способами, но эти способы скорее попытка уменьшить его
поток, чем избавиться от него совсем. Для кардинального решения
проблемы спама был разработан протокол ngmp (Next Generation Mail
Protocol - http://ngmp.libretech.org/).
Общий смысл в том, что все отправляемые письма располагаются на
сервере отправителя, а получателю через IM сервер (предполагается
использовать jabber) посылается предупреждение о наличии входящего
сообщения. Получатель при желании может либо получить весь текст этого
сообщения, либо проигнорировать его, либо аннулировать. Кроме того,
думаю, будут предусмотрены механизмы внесения юзером конкретных серверов
с которых приходит предупреждения в черный список (рекламу ведь могут и
в заголовках сообщения присыл ать, например, в теме письма).
Но у данного протокола в том виде в каком он описан на
http://ngmp.libretech.org/ есть один, как мне кажеться, огромный
недостаток - для его использования нужна полная замена программного
обеспечения у клиента. Это может очень сильно задержать внедрение
данного протокола.
Поэтому я предлагаю другой вариант его использования, который я назвал
"совместимый". При этом клиентское ПО меняется очень слабо - небольшие
изменения коснуться только jabber клиента. Почтовые-же клиенты останутся
теми-же. А вот взаимодействие серверов между собой будет идти уже с
использованием протокола ngmp.
Ну, теперь перейдем к конкретике. Я не буду подробно останавливаться на
самом ngmp - я только опишу свой вариант организации взаимодействия
клиентов и серверов.
Итак. Ситуация - отправитель шлет получателю письмо.
1. Письмо от отправителя уходит на сервер отправителя через обычный smtp;
2. Сервер отправителя проверяет сервер получателя на предмет наличия
активного jabber сервера (и каким-либо еще способом проверяет
совместимость сервера в ngmp - через специальную запись в DNS например);
3. Если все условия ngmp поддержки присутствуют на сервере получателя,
то сервер отправителя формирует ngmp notification на jabber адрес
получателя совпадающий с адресом получателя письма;
4. При получании ngmp notification через jabber клиент, получатель может
выбрать одно из действий:
- "Получить" - серверу получателя отправляется сигнал, по которому он
скачивает данное сообщение с сервера отправителя и помещает его в
стандартную очередь обработки smtp сообщений (для реализации этого
видимо придется активировать еще один порт типа ngmp-actions);
- "Игнорировать" - ничего не делать с письмом, только удалить данное
предупреждение из очереди. Письмо остается лежать на сервере
отправителя (это нужно для переполнения серверов злобных спамеров:);
- "Аннулировать" - серверу получателя отправляется сигнал об удалении
письма. Сервер получателя отправляет сигнал серверу отправителя об
удалении данного письма;
- "Поместить сервер в черный список" - сервер с которого пришло данное
сообщение поместить в "черный список". В дальшейшем сообщения с этого
сервера автоматически игнорировать;
- "Поместить сервер в белый список" - сервер с которого пришло данное
сообщение поместить в "белый список". В дальшейшем сообщения с этого
сервера автоматически принимать.
В случае, если сервер получателя несовместим с протоколом ngmp письмо
отправляется обычным образом через smtp. В данном случае нужно
использовать спам фильтры по содержимому сообщений. Само собой, что
фильтровать на спам сообщения пришедшие по каналам ngmp не имеет
никакого смысла. :) Эти сообщения можно использовать для обучения
программ фильтрации в качестве заведомо НЕ спам сообщений.
В данный момент хотелось-бы сделать патчи для postfix для поддержки
данного режима работы (я так понимаю, что для этого достаточно сделать
один или несколько фильтров и транспорт) и сделать поддержку получения
ngmp предупреждений хотя-бы в одном jabber клиенте (psi был-бы в самый
раз :). Естественно, что перед этим, как минимум, необходимо разработать
протокол передачи выбора действия клиентом службе получения ngmp
сообщений на своем сервере. Хотя, как раз функционал получения ngmp
письма можно реализовать не в контексте MTA, а совершенно отдельным
модулем с последующей пересылкой на локальный smtp (как это реализовано,
например, в fetchmail). Но вот функционал доставки исходящего письма
придется интегрировать в MTA (проверка ngmp совместимости сервера
получателя, размещение сообщения в очереди ngmp сообщений на отправку).
А менеджер исходящих ngmp писем (отправка предупреждения для новых писем
в очереди на отправку и передача тела письма при запросе с сервера
получателя) можно реализовать так-же отдельным модулем.
В общем, пока это все предоставлено для обсуждения.
From: Marmot <marmot at smtp.ru>
Еще один взгляд на проблемы NGMP
--------------------------------
Данная статья является ответом на статью Андрея Великоредчанина "NGMP -
новый протокол передачи почты. Совместимый вариант (ngmp compatible).".
Изначально планировался простой ответ, но к сожалению он "разбух" до
больших размеров.
Преамбула.
----------
Мы тут недавно тоже обсуждали проблемы NGMP, включая некоторые уже
известные предложения по его "улучшению". В результате, как водится, к
одному взгляду на вещи не пришли, но вариантов "разобрали" множество.
Привожу собственные рассуждения по этому вопросу.
Амбула.
-------
1. Понятно, что любые антиспамовые решения для smtp будут "заплатками".
Поэтому необходимость нового технологического решения очевидна.
2. Очевидно, что задача продвижения совершенно нового
протокола(решения), заменяющего smtp, является достаточно неблагородным
делом, и для массового его применения надо потратить немало сил (в силу
естествееной консервативности общества)и иметь очень сильные
преимущества самого решения (что ясно по сути).
3. NGMP, включая многие предложения по его модификации, при правильном
технологическом подходе обладают рядом серьезных недостатков, а именно:
- практически полная замена серверного и клиентского ПО. Само по себе
это не есть проблема, но существенно затрудняет процесс внедрения и
привлекательность решения.
- решение постоено на основании того, что smtp является "почти
правильным" и его надо "улучшить" до требуемых характеристик. Сама
идея NGMP и структура предлагаемых систем во многом унаследована от
того, что и как реализовано в smtp. С учетом предыдущего пункта не
совсем понятна целесообразность такого подхода.
- подход к проблеме миграции на новый протокол, на мой взгляд,
достаточно порочен. Предлагается использовать параллельно работающий
smtp, что, по сути, превращает NGMP в "заплатку" или "довесок" smtp.
Совершенно не учитывается тот постулат, от которого отталкивались при
создании самой идеи ngmp (затруднить передачу спама, сделать
малореальной подмену адресов). В предлагаемом решении параллельно
работающий smtp по прежнему является открытой лазейкой для спамеров.
Собственно предложение
----------------------
Основная идея, заложенная в ngmp, является верной. Надо не принимать
сообщения до тех пор, пока не будет принято решение о его необходимости,
которое принимается на основании "квитанции" (ala как во времена до
появления экспресс-служб доставлялись посылки).
Предлагается следующий вариант работы (отправитель - S; сервер
отправителя - SA; получатель - R; сервер получателя - RA).
1. S отправляет сообщение на SA, который сохраняет его для дальнейшей
передачи (целесообразно было бы указывать время жизни сообщения в
качестве одного из параметров)
2. SA устанавливает соединение с RA и передает ему Уникальную
"квитанцию" (ST), включая ID сообщения, время жизни сообщения,
всевозможные "срезы" сообщения.
3. В этом же соединении RA передает свою уникальную "квитанцию" для
данного сообщения (RT), включая ID сообщения, возможные параметры
пердачи сообщения и т.п..
4. Когда R устанавливает соединение с RA, то он получает все пары ST+RT,
предназначенные ему.
5. R _сам_ устанавливает соединение с SA и предъявляет ему ST.
6. SA в этом же соединении передает ему RT, полученный от RA.
7. R проверяет, что полученный RT соответствует имеющемуся у него. В
случае, если он не совпадает, то соединение разрывается и полученные
"квитанции" удаляются (отказ от сообщения).
8. При совпадении - принимается тело сообщения.
Основная разница с ngmp:
- Клиент сам забирает сообщение!
- используется двухсторонняя аутентификация на основе квитанций, что
затрудняет массовую рассылку спама (SA обязательно необходимо хранить
квитанции, полученные от RA).
- нет специальных требований к содержанию квитанций, поэтому в качестве
части квитанции можно использовать, например, цифровую подпись.
Основная идея состоит в том, что не порождать замену smtp в явном виде,
а расширить функциональность jabber до возможности передачи offline
сообщений!!!
Т.е. SA представляет собой расширенный сервер Jabber c возможностями
клиента, RA - простой сервер хранения квитанций, R и S - jabber клиент с
расширенными функциями.
Резюме:
-------
Если есть возможность, то не стоит изобретать новый велосипед и не надо
латать разваливающийся, надо попытаться модернизировать уже имеющийся и
работоспособный.
421 Прочтений • [NGMP - новый протокол передачи почты. Совместимый вариант (ngmp compatible). (mail smtp)] [08.05.2012] [Комментариев: 0]
Vova
