Quoting Jerrale G <jerrale@sheltoncomputers.com>:

On 8/14/2010 11:46 PM, Dave Stevens wrote:

...

Hi,

I have a problem on my server. To illustrate, I created a new user,
unclewiggly, and set up a password. I then used sent an email from
my usual account. Logging in with my browser I am able to see the
inbox, the mail and contents correctly. I then set up a new
instance of Eudora 7.1 on my windows 7 box with the appropriate
login id and check the account using the correct password. The
fetch fails with the client reporting an authentication failure.

Ideas? Places to look? Logfiles I can search? Maillog doesn't seem
very informative, should I send a snippet?

Thanks,

Dave

Please include the entire auth default {} section and any files
referenced within.

like this: it isn't clear to me if this is all you need.

Dave

auth default {

Space separated list of wanted authentication mechanisms:

plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi

mechanisms = plain

Password database is used to verify user's password (and nothing more).

You can have multiple passdbs and userdbs. This is useful if you want to

allow both system users (/etc/passwd) and virtual users to login without

duplicating the system users into virtual database.

http://wiki.dovecot.org/PasswordDatabase

By adding master=yes setting inside a passdb you make the passdb a list

of "master users", who can log in as anyone else. Unless you're using PAM,

you probably still want the destination user to be looked up from passdb

that it really exists. This can be done by adding pass=yes setting to the

master passdb.

http://wiki.dovecot.org/MasterPassword

Users can be temporarily disabled by adding a passdb with deny=yes.

If the user is found from that database, authentication will fail.

The deny passdb should always be specified before others, so it gets

checked first. Here's an example:

#passdb passwd-file { # File contains a list of usernames, one per line #args = /etc/dovecot.deny #deny = yes #}

PAM authentication. Preferred nowadays by most systems.

Note that PAM can only be used to verify if user's password is correct,

so it can't be used as userdb. If you don't want to use a separate user

database (passwd usually), you can use static userdb.

REMEMBER: You'll need /etc/pam.d/dovecot file created for PAM

authentication to actually work.

http://wiki.dovecot.org/PasswordDatabase/PAM

passdb pam { # [session=yes] [setcred=yes] [cache_key=<key>] [<service name>] # # session=yes makes Dovecot open and immediately close PAM session. Some # PAM plugins need this to work, such as pam_mkhomedir. # # setcred=yes makes Dovecot establish PAM credentials if some PAM plugins # need that. They aren't ever deleted though, so this isn't enabled by # default. # # cache_key can be used to enable authentication caching for PAM # (auth_cache_size also needs to be set). It isn't enabled by default # because PAM modules can do all kinds of checks besides checking
password, # such as checking IP address. Dovecot can't know about these checks # without some help. cache_key is simply a list of variables (see # doc/variables.txt) which must match for the cached data to be used. # Here are some examples: # %u - Username must match. Probably sufficient for most uses. # %u%r - Username and remote IP address must match. # %u%s - Username and service (ie. IMAP, POP3) must match. # # If service name is "*", it means the authenticating service name # is used, eg. pop3 or imap (/etc/pam.d/pop3, /etc/pam.d/imap). # # Some examples: # args = session=yes * # args = cache_key=%u dovecot #args = dovecot }

/etc/pam.d/dovecot is:

#%PAM-1.0 auth required pam_nologin.so auth include system-auth account include system-auth session include system-auth dovecot (END)

Jerrale G. SC Senior Admin

-- "It is no measure of health to be well adjusted to a profoundly sick society." Krishnamurti