Solved

Sendmail - simple step by step for smtp server set up to authenticate - users send from  anywhere to anywhere

Posted on 2004-04-04
30
3,191 Views
Last Modified: 2013-12-17
Here's the scenario - very very simple

On Redhat Enterprise ver 3 ...

Need smtp server of sendmail to accept "outbound" email sent by only users who authenticate ... users may be on LAN with the mail server and users may be connecting to smtp server from anywhere in internet.  We want them to have their email clients do a plain text login into the smtp server before it'll relay their outbound email.

I've enabled the generic authentication in the sendmail.mc file.

define(`confAUTH_OPTIONS', `A p')dnl
   ....
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
 ....
Questions include:

1.  what do I need to add to the "access db" to allow outbound relay from any IP (on lan or wan)
2.  can I have users use the same username/password we set up for them to use when connecting to get POP(3) email?  ... Do I really need to set up a separate username/pwd file/db?
3.  What else do I need to do?

Thanks for any / all help!  
0
Comment
Question by:grant-ellsworth
  • 14
  • 12
  • 2
30 Comments
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
The sefault configuration on RedHat is to use saslauthd, which will authenticat users to the system passwd/shadow file. Make sure that saslauthd is enabled (/sbin/chkconfig saslauthd on') and running (/sbin/service saslauthd start). Then configure a client to do SMTP authentication and that client should be able to authenticate and relay thorugh the server.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Solution seems incomplete.  Here's what I did:

On RH Linux, as root i performed "chkconfig saslauthd on" and then "service saslauthd start".  No problems reported - all operations reported "[OK]".

I then went to email client on other computer outside of lan :
1.  I set smtp login/pwd to the user's username and pwd
2.  I indicated login to use plaintext password.

I sent message via that smtp server and got following message(s)
   504 5.3.3 AUTH mechanism LOGIN not available

What next?
 
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
Sorry, I dind't see it until just now, but comment out "define(`confAUTH_OPTIONS', `A p')dnl" and leave "define(`confAUTH_OPTIONS', `A')dnl" in the mc file. Then build a new sendmail.cf and restart sendmail. With AUTH_OPTIONS set to "A p" sendmail will only offer the plaintext methods (LOGIN & PLAIN) if the connection from the client is encrypted.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
It didn't work.  I tried a couple of things ...

1.  commenting out entirely the "define(`confAUTH_OPTIONS', `A p') dnl line
--- by itself, I still got the "AUTH mechanism ..." message
2.  adding/enabling the "define(`confAUTH_OPTIONS', `A') dnl" statement ...
--- It changed the message, but user still could not send email via the smtp server ..
--- We saw message "535 5.70 Authentication failed"

Additional info ...
User was created thru the Linux Users and Groups applet. User can login with assigned username/password to get popmail in the queue with no problems.

When I generate the sendmail.cf with NO AUTH-related macros, but do add an IP-address for the user's machine to the access.db, the user can send mail via the smtp server.  When I remove the IP address - user's email is not accepted or relayed.  We really need a simple authentication with no binding to user workstation IP address since user may be mobile and accessing the internet to get and send mail from anywhere/anywhen on anybody's computer.

This mess begs some questions:

1.  Do I have to build or generate a separate username / password list for the smtp server to relay outbound email from remote computers/users?
2.  Is there some macro in the sendmail.mc file that is needed to hook the authentication to the Linux opsys user/pwd database?

Thx.
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
(1) That depends on whether /usr/lib/sasl2/Sendmail.conf is configured for saslauthd (auth against system passwd file, or auxprop (auth against sasldb2). When using saslauthd the methods are limited to LOGIN and PLAIN. Using auxprop allows DIGEST-MDS, CRAM-MD5, LOGIN & PLAIN if the following are in the sendmail.mc:

define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

When using auxprop it is important that the hostname of the server not change during boot and that /etc/sysconfig/network contains:

HOSTNAME=this-srv.domain.tld

and that /etc/hosts contains:

127.0.0.1      localhost.localdomain localhost
111.2.3.4      this-srv.domain.tld this-srv

replacing this-srv.domain.tld and 111.2.3.4 with the data relevant to your server. After configuring sendmail you can check the offered auth medhods by telneting to port 25 on the server and giving it an EHLO or HELO command, like:

chaos> telnet praetorian.entrophy-free.net 25
Trying 10.1.0.254...
Connected to praetorian.entrophy-free.net.
Escape character is '^]'.
220 praetorian.entrophy-free.net ESMTP Sendmail 8.12.10/8.12.10; Mon, 5 Apr 2004 19:07:47 -0500
EHLO chaos.entrophy-free.net
250-praetorian.entrophy-free.net Hello chaos.entrophy-free.net [10.1.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 50000000
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
 
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Thanks for the info about auxprop - but I'm looking to keep this setup as simple as possible.  

I looked into the sasl2 Sendmail.conf and smptd.conf files and found one line in both and both were the same:
pwcheck_method:sasl2authd
--- I did notice that smtpd.conf had one space after the ":" and Sendmail.conf did not.

Also, as I noted in original post, my sendmail.mc has:
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

Should I remove the extra authentication methods from the macros???
==========
When I telnetted in as : telnet mydomain.tld 25 and ran the ehlo command, I saw almost exactly what you illustrated ...

220 localhost.localdomain ESMTP Sendmail 8.12.10/8.12.10; Mon, 5 Apr 2004 21:21:
00 -0400
250-localhost.localdomain Hello h-xxxxx.mclnva23.xxxx.net [nn.nn.nn.nn], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP

Note all the items displayed on the AUTH line.
====================

Should I "simplify" the macros by removing ALL the other authentication methods except 'LOGIN PLAIN' and leaving the term "EXTERNAL"(??) ??

What can I try now?

Thx!
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
> --- I did notice that smtpd.conf had one space after the ":" and Sendmail.conf did not.

The space isn't significant.

> Should I "simplify" the macros by removing ALL the other authentication methods except 'LOGIN PLAIN'

That depends on whether you are going to use auxprop or saslauthd as the authentication source. Using saslauthd you can only use LOGIN or PLAIN, which are both plain text methods and have the corresponding security risks. Using auxprop all the other methods (except GSSAPI) are available and DIGEST-MD5 & CRAM-MD5 are secure in that the user password isn't transmitted in plain text. There's no point in advertising a method that Sendmail can't actually use, so it would make sense to only offer LOGIN & PLAIN if you are using saslauthd.

I like to keep my options open and allow any client that can use the secure forms to do so. Accordingly I use auxprop as the auth source and create user auth info in /etc/sasldb2 with saslpasswd2.

It sounds like everything is correctly configured at present, so a client should be able to authenticate. I can't remember if Sendmail follows it's usual pattern of downcasing user names when authenticating, so that might be something to watch out for. Passwords are case sensitive.


0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Well, the client was not able to authenticate with sendmail.mc/.cf and ../sasl2/sendmail.conf, smtpd.conf set up the way we have been discussing.  I have also verified any case-related presentation of username/passwords ,,, the same username and pwd gets the user into the popmail to retrive.  Where else, if anywhere, do I look for "problems" blocking the plain-login authenticating against the linux system's user/pwd list??  
--- I will simplify the macros to use only LOGIN and PLAIN to see if that works.  Is it possible that the code in sendmail authentication process (or code in sasl2 processing) will direct sasl to use the sasl2 database if the other methods were specified in the parameters even tho they aren't used?
-----------------------
We don't want to use thesasldb2 withe saslpassword2 since that involves having to manage 2 sets of files when we add an email user to our set.  That is just plain clumsy and inefficient and prone for clerical error.
-----------------------
In summary, what else do I need to do to enable the setup we have been discussing to authenticate remote client smtp users using LOGIN / PLAINtext???
-------------
Thanks.
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
If you are willing to live with only having LOGIN & PLAIN as methods change /usr/lib/sasl2/Sendmail.conf to read:

pwcheck: saslauthd

Make sure that the saslauthd daemon is set to start at boot (chkconfig saslauthd on) and that the daemon is started (service saslauthd start). Then restart sendmail. At this point authentication will only be done against information is the system passwd/shadow files.

If a client still can't authenticate you'll need to enable telemetry of Sendmail by starting up the MTA logging enabled, like:

service sendmail stop
/usr/sbin/sendmail -bd -q15m -X /tmp/sendmail-log

Attempt a connection from a properly configured client and then execute:

killall sendmail
service sendmail start

/tmp/sendmail-log should now contain a full record of the exchange between the client and Sendmail. You'll find the notes at http://www.sendmail.org/~ca/email/authrealms.html#authexamples helpful in interpreting what you see in the log. The authentication data is base64 encoded and you can get a suitable decoder from http://www.sendmail.org/~ca/email/prgs/ed64.c
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
In reply - yes we are willing to have only LOGIN and PLAIN as methods at this time.  Also, we already had ../sasl2/sendmail.conf have on line that reads "pwcheck_method:saslauthd" (see earlier reply/comment); I assume that what you meant was to use that statement --- "pwcheck:saslauthd" - that is, you left out the "_method" ... or is that something different?  Anyhow, the sendmail.conf was configured the way I described out of the box.  And when we tried to authenticate, it didn't happen.
--------
Further question : Have you ever set up sendmail for smtp with the "simple" eviroment I describe?  Has anybody? Or is it such a strong convention to set up smtp authentication to use these other methods that require the use of the separate saslpass2 and sasldb2 files that nobocy has even bothered trying this in recent memory?
=====================
If you are willing to live with only having LOGIN & PLAIN as methods change /usr/lib/sasl2/Sendmail.conf to read:

pwcheck: saslauthd

Make sure that the saslauthd daemon is set to start at boot (chkconfig saslauthd on) and that the daemon is started (service saslauthd start). Then restart sendmail. At this point authentication will only be done against information is the system passwd/shadow files.

0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
Yes, I meant to type 'pwcheck_method: saslauth'.

> Have you ever set up sendmail for smtp with the "simple" environment I describe?

Yes, a number of times. I'm not sure what's failing and you are probably going to have to log a transaction to see what's happening, as described above.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
I logged the transaction and decoded it.  The prompts look right - the client/remote sent in the correct username and pwd exactly as set up in the user/groups applet in Linux box.  I am thoroughly stumped.  The way this thing is behaving is that it's looking for the username/pwd somplace else besides the standard username/pwd list.
-- Question: why are we putting the pwcheck_method:saslauthd in the smtp.conf file too?  
--- For clarificatation and possibly related info:
1.  access db has entry for the domain on t he Linux computer(ourdomain.tld  RELAY)
2.  the docs at sendmail.org said t hat the sasl processing would append "@host.domain" to the user name before processing it with Login Plain via saslauthd ...
3.  appending @ourdomain.tld to the username at temote email client didn't make any difference - still won't authenticate.
4.  all necessary demons were started
Would it help if I posted the sendmail.mc/sendmail.cf, access, Sendmail.conf, etc.. with edits to protect the guilty?

We may be stuck having to use the sasl extra databases, redundant data entry of uids pwds, etc., ... argh .... We need a cleaner solution ... If I didn't want to lock down the individual client users so they would have to relay as themselves, I would do the sasl setup as you described and have all the remotes use the same userid/pwd for the smtp relay.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Rephrases prev message .. error error in sentence/question corrected here:
-- Question: why AREN'T we putting the pwcheck_method:saslauthd in the smtp.conf file too?  
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
> Question: why AREN'T we putting the pwcheck_method:saslauthd in the smtp.conf file too?

Because sendmail doesn't use that file, it only uses Sendmail.conf.

As a debugging execise, I'd suggest creating a test account with saslpasswd2, changing Sendmail.conf to 'pwcheck_method:auxprop" and see if that works. If it does that says that the Sendmail config is correct and the problem lies with saslauthd. If it doesn't work there's something wrong with the Sendmail config. Note that when using sasldb the hostname shown in the SMTP welcome banner must be the same as what 'hostname' returns. It that condition isn't satisfied the hostname from the SMTP banner must be used as the realm in the saslpasswd2 command.
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
We just got back to this unsolved problem after an unavoidable long detour.

Before trying what you describe, I did some further checking of the basic setup and noted that:

When I ran the command "saslauthd -V" from the command prompt, the messages displayed led off with:

"saslauthd[10067} :main                  no authentication mechanism specified"

----------  Does this indicate anything wrong with config that we can fix?
============================
When doing what you describe, the attempt to use smpt authentication did fail - still got notice that authentication failed.

I note the following:

1.  On client computer, email smtp server access includes only the user name.
2.  When creating the username/password using saslpasswd2, I did not specify a domain name anywhere - I just created the user via "saslpasswd2 <username>"
and responded to the password prompts.
3.  When I use Telnet to access the smtp server (telnet mydomain.com 25), the banner says "220 localhost.localdomain ESMTP ..."
    This is not the domain I am expecting - I'm expecting mydomain.com ...
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
(3) Says that you still have a system configuration problem and that might be at the root of your current difficulties. See my previous comment of 4/5/2004 for how the server must be set up, hostname wise. Note that the SMTP banner should not say "220 mydomain.com..." but rather should say "220 hostname.mydomain.com..." and "hostname.mydomain.com" must match what the 'hostname' command returns.

This must be fixed before we proceed further.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
No such luck.

I changed/confirmed that the /etc/sysconfig/network file had line "HOSTNAME=myserver.mydomain.com" and hosts file had "1.2.3.4   myserver.mydomain.com  myserver".

Telnet to mydomain.com (myserver.mydomain.com) via port 25, I saw message:

220 myserver.mydomain.com ....

exactly as I keyed it in the /etc/sysconfig/network  file.  "hostname" command returned the same value.

I tried to sendmail from client using BOTH sasl2 configs for Sendmail.conf.  Still got msg at client - Authentication failed.
1.  pwcheck_method:saslauthd  using system login and pwd for client user
2.  pwcheck_method:auxprop   using unique userid and pwd created only in sasldb with saslpasswd2

Does the access.db need to contain an entry for "myserver.mydomain.com" if it already has an entry for "mydomain.com?"

So, by your commentary on 4/11 debugging exercise, this would indicate that the sendmail.mc / sendmail.cf is flawed.  I have been over this thing many times and see nothing wrong in the areas I changed based on our earlier discussion.  Here's the sendmail.mc file.  Only change from real mccoy is the substitution of "myrealdomain.com" for the real domain.


divert(-1)dnl
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     make -C /etc/mail
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Red Hat Linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
dnl define(`SMART_HOST',`smtp.your.provider')
dnl #
define(`confDEF_USER_ID',``8:12'')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl *** define(`confAUTH_OPTIONS', `A p')dnl
define(`confAUTH_OPTIONS', `A')
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl #
dnl # TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl # define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     make -C /usr/share/ssl/certs usage
dnl #
dnl define(`confCACERT_PATH',`/usr/share/ssl/certs')
dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl # NOTE: binding both IPv4 and IPv6 daemon to the same port requires
dnl #       a kernel patch
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
LOCAL_DOMAIN(`myrealdomain.com')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS(`mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
With the hostname correctly set you don't need "LOCAL_DOMAIN(`myrealdomain.com')dnl" in the sendmail.mc and I'd recommend that you comment it out. The only other thing that I see that's less than optimal is that "define(`confAUTH_OPTIONS', `A')" is defined twice. You should remove the second copy.

Now that the hostname is correctly set and that sendmail is starting up with the correct identity I'd like to see you remove any identities you've created with saslpasswd2. Then add a one or more email account login names (saslpasswd2 userid), verify that it exists like:

chaos# sudo sasldblistusers2 | grep userid
userid@myserver.mydomain.com: userPassword

Also verify that /usr/lib/sasl2/Sendmail.conf contains:

pwcheck_method: auxprop

and that the permissions on /etc/sasldb2 are read/write for root and read for group mail. Then restart sendmail and try a client SMTP connection (making sure that the client is set to use LOGIN or PLAIN).
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Your recommendations beg a few questions:

1.  Is commenting out the "redundant" Local_Domain(....) absolutely necessary - that is, is it possible to cause the misbehavior I'm experiencing?
2.  Is the redundant "define(confAUTH ... ) " a likely cause of the misbehavior?

3.  Am I supposed to remove the userid I created to test previous "pwcheck_method:auxprop" setup and create a new one only in the sasldb2 using saslpasswd2

4.  is ls -ls /etc/sasldb2 results "-rw-r-----" showing the privs set the way they should be?
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
(1) I don't know if it might cause problems or not. It is probably safer to leave the localhost.localdomain defintion in the mc file and to use /etc/mail/local-host-names for the system identities, like:

localhost.localdomain
localdomain
myserver.mydomain.com
mydomain.com

(2) No.

(3) Yes. I think that a sasldblistusers2 will show the wrong realm for the account(s).

(4) You should see:

-rw-r-----    1 root    mail        86016 Apr 23 10:05 /etc/sasldb2
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Some progress, at last.  When I added the userid, I noted that sudo sasldblistuser2 displayed :
"mynewuser@myserver.myrealdomain.com"
---
Then I went to client/remote where i set up smtp authentication username as:
"mynewuser"
the smtp server did not reject with authentication error. The mail did go thru.

(If I forced the username into the sasldb2 via "saslpasswd2 -c -u myrealdomain.com mynewuser" and create user as "mynewuser@myrealdomain.com", we would still get authentication error!)

HOWEVER: Removing "Local_Domain(`myrealldomain.com') caused the inbound mail to be rejected with message back to sender about "looping back to myself ..." . So, I restored the parameter to sendmain.mc, etc..  Does the "local-host-names" file accomplish the same objective?

Now that we have the pwcheck_method:auxprop working ... How do we set up so that we can use the pwcheck_method:saslauthd, as originally intended - that is, to use the system password file instead of the auxilliary "sasldb2" file??
0
 
LVL 40

Expert Comment

by:jlevie
Comment Utility
Okay, progress... Now that the hostname issue appears to be fixed and the auth info in sasldb2 matches what sendmail is expecting it should, and does, work. When sendmail attempts to authenticate it will append the username to the hostname sendmail was started as and ask SASL to authenticate that user. This means that the realm in sasldb2 for the user must be the same hostname that sendmail saw when it started. That's why I wanted you to remove any accounts in sasldb2 and recreate them with the system's hostname now correct. It is also why you can't authenticate against a user with a realm of "mydomain.com".

"Mail loops back to me" is the classic case of sendmail not knowing all of the host and domain names that it is to accept mail for, in the general case. As cited earlier the preferred way of dealing with this is to include all of the host and domain names in /etc/mail/local-host-names. Since that's a simple file read each time sendmail starts it is much easier to maintain and less clumbersome that a bunch of "LOCAL_DOMAIN) definitions in sendmail.mc.

But, having said that, it seems to me that there's still something odd going on. Even with an empty local-host-names file and no LOCAL_DOMAIN definitions in sendmail.mc you should have been able to receive mail addressed to user@mydomain.com providing that the hostname of the machine was my-server.mydomain.com and that the hosts file contained a record that equated the IP of the machine to my-server.mydomain.com. Under those conditions sendmail defaults to accepting mail for user@my-server.mydomain.com and user@mydomain.com.  It seems to me like the only thing that would upset that would be trying to send mail to user@otherdomain.com or if a DNS lookup on the IP of your mail server returned something other than my-server.mydomain.com. Could either of those be the case?

Providing there's not anything odd going on with the hostname, switching to saslauthd should work now that we've proved that SMTP auth against sasldb2 does work.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
I got one step ahead of you and tried to retreat to pwcheck_method:saslauthd - still fails.

other info:

Onthe mail server, the Hosts file contains line / entry for 1.2.3.4  myserver.myrealdomain.com myserver

While we have "A" records in the DNS for "smtp.myrealdomain.com" and "pop3.myrealdomain.com" -- both pointing at the public IP address of myserver.myrealdomain.com, we have NO DNS "A" record for "myserver.myrealdomain.com".  We only have the HOSTS entry in the /etc/hosts file on myserver - no entries on the client workstation HOSTS file for the server.  The email client specifies either "1.2.3.4" or "smtp.myrealdomain.com" as the smtp server.  We were trying to use the smtp to relay outbound mail --- that is, email from client whose email destination was "otherusername@otherdomain-notmyrealdomain.com".

Without the LOCAL_DOMAIN definition in sendmail.mc, inbound mail (mail for user@myurealdomain.com) loops.  I haven't tried the local-host-names file yet.

Where you wrote " ... or if a DNS lookup on the IP of your mail server returned something other than myserver.myrealdomain.com", where/which computer are you referring to as issuing the request for name/ip resolution --- the client or the server?  

Where to from here?  Seems like there's a very minor detail giving me a very major headache!
0
 
LVL 40

Accepted Solution

by:
jlevie earned 250 total points
Comment Utility
I suspect that the misconfigured DNS is part of your problem. What you should have in the DNS is  A and PTR records for my-server.mydomain.com and CNAME records for smtp.myrealdomain.com point to the my-server.mydomain.com. That sort of mis-configuration may cause saslauthd to lookup the wrong user@realm when it attempts to authenticate the user.
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
Sorry about this - we almost made it work - close, but no cigar.  I gave up on sendmail and installed qmailrocks - my problem was solved and my requirements met.

Call this case closed.

- Grant
0
 
LVL 11

Expert Comment

by:turn123
Comment Utility
If you want to PAQ this question, post a zero-point question in http://www.experts-exchange.com/Community_Support/

Subject: Moderator Please PAQ
Body: Please PAQ this question:
http://www.experts-exchange.com/Networking/Email_Groupware/Sendmail/Q_20943390.html
0
 
LVL 11

Expert Comment

by:turn123
Comment Utility
From the askers email to me "The tech expert deserves the points."
0
 
LVL 1

Author Comment

by:grant-ellsworth
Comment Utility
JLevie identified the several sources of the difficulty.  However, there was one finaol set of ?? that a tech expert had to do to make this all work = I don't understand what had to be done - it did have something to do with file security settings.  wht a mess.  when we got it all done and working, we found the sendmail feature was not sufficient to the task required.  Case closed. thanks for the help.
0

Featured Post

Want to promote your upcoming event?

Are you going to an event? Are you going to be exhibiting at a tradeshow? Talking at a conference? Using a promotional banner in your email signature ensures that your organization’s most important contacts stay in the know and can potentially spread the word about the event.

Join & Write a Comment

Granting full access permission allows users to access mailboxes present in their database. By giving full access permission one can open and read the content of any mailbox but cannot send emails from that mailbox.
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
Familiarize people with the process of retrieving data from SQL Server using an Access pass-thru query. Microsoft Access is a very powerful client/server development tool. One of the ways that you can retrieve data from a SQL Server is by using a pa…
In this video we show how to create a Resource Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: Navigate to the Recipients >> Resources tab.: "Recipients" is our default selection …

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now