1. Forum
  2. FidoNet
  3. FTSC PUBLIC

  • OPT MPWD interpretation...

    From Ozz Nixon@1:1/123 to ALL on Fri Mar 6 22:42:46 2020
    Okay, while working with another BinkP mailer developer ~ we had
    different opinions of the wording and functionality of MPWD support.

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

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

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

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

    Thank you,
    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Joachim Probst@2:240/6309 to Ozz Nixon on Sat Mar 7 11:19:12 2020
    Hello Ozz!

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

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

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

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

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

    I know most people just match their passwords, but, a couple
    situations, the password was out of my control ... and I would like to implement M_PWD support ... (this may be a BinkD question in some
    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.

    Thank you,
    Ozz

    Joachim


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