On 10-Mar-2003 13:55 Charlie Brady wrote:
|
| > Only insofar as they want to provide (nearly) the same functionality.
| > It's certainly much easier to scrutinize the patch.
|
| No, both are built on tcpserver - one as an explicit patch, the other as a
| "new" package which used tcpserver as a starting point.
We're splitting hairs; there's no need to be pedantic.
| Yes. In particular, I'm interested in the privilege separation
| capabilities of Scott Gifford's patch, and more flexible authentication
| capability. It's also a Good Thing if none of bincimap ever runs as root.
Certainly.
| An IMAP server MAY advertise that the
| LOGIN command is disabled by including the LOGINDISABLED capability
| in the capability response.
| ...
|
| An IMAP server which implements STARTTLS MUST implement support for
| the LOGINDISABLED capability on unencrypted connections.
|
| An IMAP client which complies with this specification MUST NOT issue
| the LOGIN command if this capability is present.
|
| So, how does the server implement "LOGINDISABLED" if it doesn't advertise
| the capability in the capability response?
It is somewhat vague, although I would certainly interpret "MUST
implement support for LOGINDISABLED capability" as meaning it must
also advertise it in the cap response; it the advertisement is moved
from MAY to MUST in this special case. Are there other circumstances
under which one might want to advertise LOGINDISABLED?
Is bincimapd behaving correctly in this respect?
|
| > As far as I can tell, it won't be able to do
| > that unless you put something else in the chain to give it the hint.
|
| If local policy required encryption, then you would set up the process
| chain so that bincimap wasn't ever executed until TLS had been negotiated
| and the client successfully authenticated.
Or you only offered tls/ssl service on ports dedicated for that purpose,
optionally disabling the same non-tls/ssl services on other ports.
STARTTLS really does seem more trouble than its worth.
--
-dale
