Subject: Sasl service name

From: Richard A Nelson <[email-masked]>
Date: Sun, 1 Apr 2001 15:38:21 -0400 (EDT)

I'd like to setup sasl so that plain-text passwords are automagically
created to more secure versions - this entails creating a configuration
file named <service>.conf in the sasl library space.

I've got sendmail, slapd already setup and would like to get pine
(c-client, really) next.

What services will pine (and/or c-client) set? I'm assuming:
 smtp (for delivery)
 imap (for reading)
 pop  (for reading)
 nntp (for reading/posting)

Are these the proper names passed to SASL? are there others?
-- 
Rick Nelson
Life'll kill ya                         -- Warren Zevon
Then you'll be dead                     -- Life'll kill ya

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 1 Apr 2001 13:19:16 -0700 (PDT)

> I've got sendmail, slapd already setup and would like to get pine

This question isn't particularly meaningful in the c-client context.  c-client
is essentially a passive player when it comes to SASL.  You're thinking about
the Cyrus/SASL way of doing things.  c-client is a completely different
implementation of SASL.

It's somewhat like asking "how do I change the Windows registry on
UNIX?"...although the strictly literal answer is "you can't do that" the more
general answer is "you accomplish things in a different way on UNIX than a
registry -- what do you want to do?"

Your message doesn't give me enough enough detail to understand your goals,
but here's a few notes that will get you started.  If you'll contact me
offline with your specific goals, I'll try to give you more specifics on how
to do it.

c-client will automatically use the most secure authentication mechanism which
it and the server mutually agree to, falling back to less secure mechanisms
(again, by mutual agreement).  This differs from the Cyrus/SASL library way of
doing things, which requires that the user know what authentication to use and
configure the client appropriately.

The downside of c-client's way of doing things is that if an authentication
mechanism requires an independent database because the /etc/passwd database is
unusable (e.g. in CRAM-MD5), and if the user is not set in the new database,
it will still try three times to authenticate via CRAM-MD5 before it will back
back to PLAIN.

The other piece of the puzzle is whether or not a PLAIN password should be
automatically registered in the other databases; e.g. should a PLAIN password
be registered in the CRAM-MD5 database?

In the c-client view of things, this is a server issue.  The c-client based
servers don't do this since in c-client there is no such thing as separate
PLAIN and CRAM-MD5 databases; if a CRAM-MD5 database exists it is also the
database for PLAIN.  The basic philosophy here is that a secure database
should not be registered via an insecure mechanism such as plaintext
passwords.