# [SOLVED] SMTP Auth & Sendmail & Gentoo

## Anquietas

Hello,

I want to set up a good E-Mail server and I've installed Sendmail and SASL and Dovecot.

No problems with dovecot, I can log in.. the mail is downloaded.. no problem...

But in Sendmail, I have a problem.. I can't find out how to configure the Sendmail to Accept a WORKING relay.

I've configured the Sendmail.mc, I've compiled with m4, and I started the daemon...

It recognizez my TLS Connection, but when I want to write a new email, and click on the "SEND" button, it asks for my password. I give the account password (the same as login to dovecot), but it reasks it again.. it does not accept my password.

I've searched on the net, and I'm pretty sure that SASLAUTHD or PAM is faulting somewhere but I cannot find out where...

===========

My SENDMAIL.MC:

define(`confAUTH_OPTIONS', `A p')dnl

TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl

define(`confCACERT_PATH', `/etc/ssl/certs')dnl

define(`confCACERT', `/etc/ssl/certs/ca-certificates.crt')dnl

define(`confSERVER_CERT', `/etc/ssl/certs/mailsys.pem')dnl

define(`confSERVER_KEY', `/etc/ssl/certs/mailsys.pem')dnl

===========

The /etc/conf.d/saslauthd:

SASLAUTHD_OPTS=""

SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -a pam"

 ===========

The /etc/pam.d/saslauthd:

#%PAM-1.0

#auth       required     pam_nologin.so

auth       include      system-auth

account    include      system-auth

session    include      system-auth

=======================

What the hell is going on and why does it not accept my password when I'm trying to AUTH to the Sendmail MTA (SMTP) ?...Last edited by Anquietas on Sun Aug 03, 2008 8:35 am; edited 1 time in total

----------

## VinzC

I know I'll probably have fire launched at me but why don't you consider Postfix/Dovecot instead? Sendmail's bloated and buggy. Postfix is a good alternative.

I have setup a mail server with Postfix and Dovecot IMAP (not using SASL authentication with SMTP though) and it works like a charm stand-alone as well as with a relay.

----------

## Anquietas

More Information:

Aug  2 15:14:36 infosky saslauthd[26878]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure

Aug  2 15:14:36 infosky saslauthd[26878]: do_auth         : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

Aug  2 15:14:36 infosky sm-mta[26895]: m72FETGO026895: AUTH failure (PLAIN): authentication failure (-13) SASL(-13): authentication failure: Password verification failed

Aug  2 15:14:36 infosky saslauthd[26877]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure

Aug  2 15:14:36 infosky saslauthd[26877]: do_auth         : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

Aug  2 15:14:36 infosky sm-mta[26895]: m72FETGO026895: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed

Aug  2 15:14:37 infosky sm-mta[26895]: m72FETGO026895: Terminal [192.168.0.3] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

...

still don't have a clue what to do  :Neutral: 

I supose it is a SASL problem  :Neutral: 

And sometimes it shows:

Aug  2 15:24:43 infosky sm-mta[27700]: m72FOZf2027700: AUTH failure (PLAIN): user not found (-20) SASL(-13): user not found: Password verification failed

Aug  2 15:24:43 infosky sm-mta[27700]: m72FOZf2027700: AUTH failure (LOGIN): user not found (-20) SASL(-13): user not found: checkpass failed

Aug  2 15:24:44 infosky sm-mta[27700]: m72FOZf2027700: Terminal [192.168.0.3] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

----------

## VinzC

First I wouldn't recommend using PAM to authenticate mail users. Why? Because it would result in giving them logon access to your mail server system somehow. In fact it wouldn't prevent such users from logging onto your mail server regularly -- be it interactively or using an exploit.

Second PAM is not advisable for virtual mail user accounts. Virtual mail users should not be granted logon access to your mail server -- which is what PAM is all about. They might end up having *permissions* on their files (e.g. if you're using a Maildir for mail repository) but no login access, which would result in a security hole.

If you absolutely need PAM for authentication (although Dovecot doesn't necessarily require it), you might check whether you have Unix accounts defined for these users. Also check the eventual ports involved in the authentication method. I'm no expert in that particular topic and cannot be more accurate. Hope it'll point you to some directions.

----------

## Anquietas

ok, thank you all, but, I fixed the problem  :Smile: 

The problem lies in the fact that in sendmail.mc I have a directive like "Mailer(SMTP)dnl" at the bottom of the file... now, I had to copy /etc/pam.d/saslauthd to /etc/pam.d/smtp ... with the exact contents, because SASLd was looking up for a "[service=smtp]" file in /etc/pam.d, because I use the SMTP protocol to Send Mail.... 

I figured out that the service=OBJECT requires that the OBJECT must have a file in /etc/pam.d/ with that same name.

And all my users are real standard users of the Linux System... I'm not setting up Virtual Emails, only Real ones... and Dovecot is set to Chroot the enviroment of the users... so they can only mess up with their account  :Smile: 

So, I've solved the problem  :Smile: 

----------

## VinzC

Good news  :Very Happy:  . So all you need to do now is append [SOLVED] to the title of your first post.

----------

## Anquietas

ohh, I didn't know that  :Razz:  Thanks

----------

