MBOX-Line: From dot at dotat.at  Mon Jan 18 07:04:00 2010
To: imap-protocol@u.washington.edu
From: Tony Finch <dot@dotat.at>
Date: Fri Jun  8 12:34:43 2018
Subject: [yam] [Imap-protocol] Re: draft-daboo-srv-email: POP3S/IMAPS?
In-Reply-To: <1fQ38Id/bDvQxBfPPns2Vg.md5@lochnagar.gulbrandsen.priv.no>
References: <9A584868-5961-4871-B32E-915394043727@sabahattin-gucukoglu.com>
	<01NIK8RBBRJK004042@mauve.mrochek.com>
	<NvmPpzLxQER/jAcfFP13kQ.md5@lochnagar.gulbrandsen.priv.no>
	<6081A14A-42E5-4139-A57D-6DF01EF86BA7@iki.fi>
	<TGqvOaec0Cbt2mg7bqct1w.md5@lochnagar.gulbrandsen.priv.no>
	<alpine.LSU.2.00.1001181332190.6203@hermes-2.csi.cam.ac.uk>
	<1fQ38Id/bDvQxBfPPns2Vg.md5@lochnagar.gulbrandsen.priv.no>
Message-ID: <alpine.LSU.2.00.1001181458000.6274@hermes-2.csi.cam.ac.uk>

On Mon, 18 Jan 2010, Arnt Gulbrandsen wrote:
>
> Timo's mail made me think of a different approach: Immediately expire a
> password if a server receives that password in clear text. Bang bang. (Let me
> guess: The words "support spike" entered your mind now.)

:-)

One advantage of POP's separate USER and PASS commands relative to IMAP's
unified LOGIN command or SASL PLAIN is that the server can reject the USER
command on unencrypted connections and with any luck the client will give
up without blurting out the password. At least in theory :-)

In practice I'm not too worried about idiot client software revealing
passwords because it'll only happen during the user's first attempts at
configuration, so the exposure is pretty small. I might revise that
opinion if a college decides to go all-wireless for network access in
student bedrooms, and if against all past experience students start using
MUAs en masse instead of webmail...

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

