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