Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 5149 из 7124 ====================================== FTSC_PUBLIC =
От   : Joachim Probst                   2:240/6309         07 Mar 20 11:19:12
Кому : Ozz Nixon                                           07 Mar 20 11:19:12
Тема : OPT MPWD interpretation...
FGHI : area://FTSC_PUBLIC?msgid=2:240/6309+5e637740
На   : area://FTSC_PUBLIC?msgid=1:1/123.0+5E62D056
= Кодировка сообщения определена как: LATIN1 =================================
==============================================================================
Hello Ozz!

06 Mar 20 22:42, you wrote to all:

ON> Okay, while working with another BinkP mailer developer ~ we had
ON> different opinions of the wording and functionality of MPWD support.

ON> If I have presented (as the answering system) Zone1 Zone99, Zone103
ON> And the originator presented Zone1 Zone103 Zone200

ON> Any we have passwords that are different for 1 and 103 - as we are
ON> each others uplink.

ON> MPWD in my understanding would be expenting the passwords presented in
ON> the order the answering system 1, 99, 103
ON> So I would be expecting to receive MsgHdr Len M_PWD pwd1 - pwd2
ON> In his mind, it is the originators order, pwd1 pwd2 -

ON> I know most people just match their passwords, but, a couple
ON> situations, the password was out of my control ... and I would like to
ON> implement M_PWD support ... (this may be a BinkD question in some
ON> heads, but, it goes wider to other mailers)... so I ask here.

Here I am completly with you, not with the way to do it, but that we have a valid point one should takle. The problem I see with the one password is: how to deal with the password matching not all but only a few akas correctly. Ignoring the session? Ignoring the akas not fitting to the password? The FTS is only working on with a correctly password protected session or not. What's with 'partly' password protected sessions?

So I really like the idea of having an authentication per aka.

But when extending the protocol on this point I would recomend doing it in a better downward compatible way.

What about introducing a new keyword, either as M_OPT MPWD <aka> <password/CRAM> or as M_MPWD <aka> <password>? The old M_PWD would still be used as with no password.

This would make a matching of password to aka fairly easy and a system could easily support old and new style in paralell, like if there is no new password line, I take a look in the old style protocol and if I see the new line I just ignore the old style password.

I would think this way would make it much clearer for interpretation.

ON> Thank you,
ON> Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin:  ----> FidoPI  (2:240/6309)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.039530 секунды