>Только вы забываете, что технология типа ICQ не подойдёт, потому что там
>_централизованно_ проверяется логин/пароль. Нужна же распределённая система. Так говорю же, что пользователь авторизует письмо на сервере, на котором получает письмо, то есть, не spamassassin, не openrbl, не кто-то, кто по каким-то причинам (порой весьма личного характера) блокирует одни адреса и разрешает другие, а _пользователь_ на _своем сервере_ разрешает или запрещает серверу получение того или иного письма - вот и распределенность. Далее, реклама тут отпадает по той простой причине, что в тело адреса отправителя можно забить не так уж и много символов - например, письмо с адресом отправителя Позвони_по_телефону_777_77_77@hotbox.ru не несет в себе абсолютно никакой информации, трафика пересылка такого заголовка съест совсем немного (один пакет сможет уместить), а уж отличить по такому адресу спам это или не спам - я думаю, не сложно. И остается только тот небольшой процент идиотов, которые сами разрешают пересылку себе на ящик писем, мягко говоря сомнительного характера. Постараюсь пошагово этот процесс описать:
1. Некий отправитель с адресом sender@sendfrom.com пишет письмо на адрес reciever@sendhere.com
2. Сервер отправителя mail.sendfrom.com отправляет заголовок (не обязательно весь) письма на сервер получателя mail.sendhere.com, скажем, только поле From.
3. Сервер получателя индексирует это письмо.
4. При проверке почты получателем сервер сообщает, что на его адрес было отправлено письмо от $From.
5. Получатель рассматривает необходимость принятия этого письма, принимает решение.
6а. Если решение о принятии отрицательное, то сервер получателя просто удаляет запись о письме. А сервер отправителя просто по таймауту его удалит, либо будет хранить до тех пор, пока не получит подтверждение на отправку.
6б. Если решение о принятии положительное, то сервер получателя отправляет серверу отправителя подтверждение пересылки письма и далее идет передача письма и, если получатель все еще ждет на связи, доставка его конечному получателю.
При этом пересылки сообщений, которые были разрешены к доставке на постоянной основе, назовем их "доверенные отправители", происходят в автоматическом режиме без участия получателя, он их просто получает уже при проверке почты на сервере.
Недостатки:
1. Необходимость для серверов с большим количеством пользователей хранить очень объемные базы данных для отправителей и получателей. При этом современные объемы носителей информации, а также производительность современных систем, я думаю, позволят организовать это без серъезных затрат для организаторов сервисов.
2. При отсутствии связи между серверами при положительной авторизации сообщения, письмо будет доставлено не сразу, а только после восстановления связи. Опять-таки, современные технологии организации магистралей internet позволяют организовать для большинства пользователей непрерывную связь между любыми двумя (и более) хостами.
Преимущества:
1. Самое главное: объемы передаваемого трафика упадут за счет уменьшения передаваемого по mail-протоколу спама (естественно!).
2. Пользователь будет _всегда_ знать, от кого и откуда он может получить письма, будет _сам_ принимать решение о приеме на свой почтовый ящик того или иного сообщения, а не дядя администратор, которому по большому счету порой наплевать на принимаемую пользователями его сервиса информацию и на ее полезность для этих пользователей.
3. Никаких глобальных сервисов, определяющих виртуальную легитимность того или иного сообщения. Это будет определяться конкретным пользователем-получателем конкретного сервера.
Концепция этой схемы доставки сообщений весьма подходит для названия Authoritative Mail Transfer Protocol (AMTP).
