On Mon, 2010-04-12 at 09:46 -0500, Mike Abbott wrote:
Consider that the submission server and the IMAP server may be unrelated, under completely different administrative domains. Separate departments of a school or business, for instance, or even different schools or businesses. You would want to allow submit users from any network to connect (securely) and authenticate.
But this feature is about allowing submit users to connect and authenticate insecurely..
But the authentication must be plain-text for submit user(s) even when regular users are forbidden from using it. RFC 4468 section 3.3 requires it: Specifically, this requires that the submit server implement a configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the IMAP server.
That says the submit server's IMAP client must support STARTTLS+SASL PLAIN authentication. Which is exactly the opposite of what X-PLAIN-SUBMIT does.
But anyway, if there really is a need for "allow submit users to authenticate insecurely, but require others to authenticate securely", maybe it could be a passdb extra field. That would still require that:
login process doesn't immediately reject plaintext auth attempts, but rather lets auth process figure out if it should be rejected
LOGINDISABLED capability is still sent to IMAP client (telling it not to do plaintext auth). Submit server would have to ignore that..