idec.talks
AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

AL> Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.

Предположим, у нас есть 3 станции по такой схеме:

====
node1 ---- node2 ---- node3
====



node1 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM