Hi Al,

 AI>>> They do, and both mailers work very well with that encryption.
 AI>>> Do mailers that support CRYPT need to negotiate a session and
 AI>>> exchange passwords before the session can be encrypted?

 Ol>> Yes, you need a shared session password. It's also not a
 Ol>> completely encrypted transmission.

 AI> This was a good start at the time it was implemeneted.

Yes and it's easy to implement.

 Ol>> AFAIK it uses opportunistic TLS (like STARTTLS).

 AI> Yes, James said that he used this method as a start because we still
 AI> need to use the current method when encryption is not supported at
 AI> both sides of the link. The idea (when it's possible) is to move away
 AI> from opportunitic TLS.

It sounds like a good idea, but it's not (IMHO). We don't have to repeat the
mistakes that others did 20 years ago. There will always be many mailers that
don't support TLS, which means it never would be possible to move away from
opportunistic encryption (by that logic).

We can just use another default port for binkps. A _binkps._tcp srv record can
point to the TLS port and a nodelist flag with optional hostname and port
parameters can indicate TLS capability.

 AI>>> Would binkp over TLS (or really, any secure method) be a good
 AI>>> thing?

 Ol>> Why wouldn't it? :)

 AI> I can't think of a reason. If we could get something to test we could
 AI> discover what works, what doesn't, and in time a standard method of
 AI> doing this could be established.

We could test direct TLS with binkp today :)


--- GoldED+/LNX 1.1.5-b20180707