On Wed, 31 Dec 2003, Paul Jarc wrote: > Ok, I'll try that. If I find that some clients can't handle it, I > guess I'll add "anonymous"-only LOGIN. In that case, do you think I > should also allow AUTH=PLAIN with "anonymous" as the username?
I don't see much point to doing that. LOGIN with anoymous as the userid is enshrined for legacy purposes (see RFC 3501 section 6.2), but not use of a userid of anonymous in a SASL mechanism such as PLAIN. A valid implementation could accept anonymous as a userid to the LOGIN command but not as a userid to a SASL mechanism. > I > guess some clients might send a real username and password belonging > to another service, only to be rejected here, but sniffers would still > get the password. But I don't know whether advertising AUTH=PLAIN > would make this any more likely. That is the risk taken with LOGIN and with AUTH=PLAIN. The safest thing is LOGINDISABLED and no AUTH=PLAIN. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
