Subj : I'm confused To : Roger Nelson From : mark lewis Date : Mon May 30 2016 08:54 am 30 May 16 06:05, you wrote to Joe Delahaye: NA>> Not a bug. DB is designed this way, and the Packet Password screen NA>> overrides the password inserted. JD>> If I understand you correctly, if you do not configure a password, JD>> but have a session pw, that will be used as the packet PW, whether it JD>> is wanted or not. Should you configure a packet password that is JD>> different then the session PW, that is the one that would be used for JD>> the packet PW RN> Maybe others should ask Chris Irwin why he did it that way and why RN> Nick left it that way, but I'm positive both have good reasons. In RN> fact, the more I think about it, the clearer it becomes. my explanations should be helping in that understanding by now, too... frontdoor ran all up into it years ago from at least one particular mailer and had to adjust for it... with today's popular tossers having been ignoring the PKT passwords and now in recent months no longer ignoring them, the problem has come to light yet again... back then the problem was limited to FA (file attach) mailers... BSO mailers generally do not have this problem where the mailer checks the password in each inbound PKT like a FA mailer might do... especially a dynamic mailer that packs its own netmail from its netmail directory... BSO mailers need only check the initial session level password in the initial handshake traffic... DB being an intelligent dynamic FA mailer is doing what intelligent dynamic FA mailers do since it processes the PKTs as well as transferring them... to compare with frontdoor, FD only unpacked netmail from the PKTs and left the echomail alone but FD, like DB, also dynamically creates PKTs of netmail for destination systems... FD has only the session level password and the very first packet exchanged between the mailers contains the session level password... that first packet is a stripped down PKT with the packet password being the session password else the two mailers won't know who they are talking to and whether the session is with the proper remote and not an impersonator... when the session is accepted, then the files on both sides are sent... those would be mail PKTs, including those PKTs dynamically packed by the mailer from its netmail directory, and tosser created mail bundles along with possibly other files and maybe accompanying TICs... with today's prolific use of the binkp protocol, which uses a completely different manner of initial handshaking and confirming the remote is the system it says it is, this problem can be excaberated by hybrid systems because the PKTs can contain a different from the session level password but valid PKT password because there is no initial empty PKT sent over binkp... binkleyterm and other BSO mailers do send an initial empty PKT with the addresses and session level password but that's the only PKT they create and process... all other PKTs, mail bundles and files are just transferred over the link... )\/(ark Always Mount a Scratch Monkey .... People who live in glass houses usually have faded sofas. --- * Origin: (1:3634/12.73) .