>ЭЭЭЭ, я бы сказал так, странно слышать о необходимости разработки нового протокола,
>когда уже дааавно сущестует х400 в котором все средства проверки отпраителя
>и гарантированная доставка существуют по дефолту, но он не прижился среди
>почтовых серверов, зато укоренился в банковской переписке. Вот так вот... А Ну, значит для внедрения x400 были какие-то сущесвтенные препятствия. Я так думаю.
>насчёт методов предложенных обоими авторами то...
>1 SMTP подтыкать костылями ((( реально не выход, необходим достаточно быстрый и
>разумный переход на новый стандарт, как серверного так и клиентского ПО.
То что я предлогаю, не подтыкание smtp костылями (SPF, спам фильтры, rbl - вот это и есть костыли для smtp), а обеспечение для ngmp временной совместимости с smtp. Главная цель - ускорение его внедрения.
>2 Может быть предложенная схема и хороша, но если посчитать количество трафика
>на передачу вот таких вот тикетов,
Какой трафик? Каждый тикет будет размером максимум 512 байт. В сравнении с сегодняшним трафиком, который создается спамом это просто смешно.
> да ещё и хранение и
>отдача сообщений не с сервера получателя, а с сервера отправителя мы
>получем немаленькую нагрузку на основные почтовые системы, я понимаю, что они
Если можно подробнее - за счет чего получается немаленькая нагрузка на основные почтовые системы? Теоритически просто меняется порядок хранения писем и слегка увеличивается нагрузка за счет уведомлений. Не вижу где тут может быть "немаленькая" нагрузка.
>расширят каналы, докупят сервера, но как быть корпоративному сектору. он то
>на это просто может не пойти посчитав расходы и их отдачу.
Еще раз - с точки зрения нагрузки на сервера и каналы я не вижу существенного ее увеличения в моем варианте. Скорее наоборот - за счет снижения трафика от спама нагрузка и на каналы и на сервера существенно снизится.
>Так что похоже решение должно быть более изящным.
x400? Тогда почему он не получил широкого распространения?
>IMHO естественно...
