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.
