We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


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

Medium Priority
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
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!  
Watch Question

Top Expert 2005

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.


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?
Top Expert 2005

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.


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?

Top Expert 2005

(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

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


and that /etc/hosts contains:      localhost.localdomain localhost      this-srv.domain.tld this-srv

replacing this-srv.domain.tld and 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
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 [], pleased to meet you
250-SIZE 50000000
250 HELP


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:
--- 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:

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 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?

Top Expert 2005

> --- 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.


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???
Top Expert 2005

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


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.

Top Expert 2005

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.


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.


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?  
Top Expert 2005

> 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.


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 ...
Top Expert 2005

(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.


No such luck.

I changed/confirmed that the /etc/sysconfig/network file had line "HOSTNAME=myserver.mydomain.com" and hosts file had "   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.

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 #
VERSIONID(`setup for Red Hat 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 #
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')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 #
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(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')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
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 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=, 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 #
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
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
Top Expert 2005

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).


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?
Top Expert 2005

(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:


(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


Some progress, at last.  When I added the userid, I noted that sudo sasldblistuser2 displayed :
Then I went to client/remote where i set up smtp authentication username as:
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??
Top Expert 2005

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.


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  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 "" 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!
Top Expert 2005
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview


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

If you want to PAQ this question, post a zero-point question in https://www.experts-exchange.com/Community_Support/

Subject: Moderator Please PAQ
Body: Please PAQ this question:

From the askers email to me "The tech expert deserves the points."


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.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.