= Сообщение: 327 из 1947 ========================================== RU.BINKD = От : Pavel Gulchouck 2:463/68 15 Jan 15 10:59:22 Кому : Ivan Agarkov 15 Jan 15 10:59:22 Тема : inconsistent pwd settings FGHI : area://RU.BINKD?msgid=2:463/68+54b783f7 На : area://RU.BINKD?msgid=2:5020/849.1+54b775c0 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.BINKD?msgid=2:5020/849.1+54b79bf2 ============================================================================== Hi Ivan!
15 Jan 15, Ivan Agarkov ==> Pavel Gulchouck:
IA> Интересно, а добавление что-то типа OPT MULTIPASS с передачей нескольких паролей - сильно усложнит систему?
Как ты это себе представляешь? Допустим, у меня есть AKA 2:463/68 и 2:46/128, для которых с твоей стороны прописаны разные пароли. Я звоню тебе на 2:5020/849. Но у меня ведь на твой узел есть только один пароль.
IA> Это могло бы избавить от некоторых проблем, например от проблем присвоения левых aka и отправки от их имени почты. IA> Если у Васи нет линка с /XXX то кто мне мешает позвонить Васе, добавить себе aka /XXX и с него заслать всем почту? Hикто, IA> и упадет это в secure inbound. А если это делает пойнт, то это еще и не наказуемо никак, пойнты нынче раздаются без IA> личного визита.
В этом, как мне кажется, нет смысла, потому что для того, чтобы отправить почту от левого адреса, совершенно необязательно подставлять этот адрес как AKA в мейлере. Предъявив адрес /XXX, можно влить pkt с src /YYY, а в этом пакете запаковать мессагу с src /ZZZ. binkd умеет проверять соответствие предъявленного aka и source-address в pkt, но pkt можно завернуть в arcmail.
В общем, FTN не защищает от хулиганства со стороны парольных линков. Точнее, защита тут немного на другом уровне: если парольный линк через тебя влил спам от поддельного адреса, получатель этого спама не будет видеть адрес настоящего отправителя, но он там увидит твой адрес, обратится к тебе, а ты по своим логам сможешь понять, откуда тебе это письмо попало, и принять меры.