Link to home
Start Free TrialLog in
Avatar of navigator010897
navigator010897

asked on

Sendmail SMTP configuration question

Hi All,

Ok, I'm trying to secure up sendmail's relaying capability.

Here's what I want to do:

Have local users on the network be able to send email thru my email server.

Have remote users on other networks that have local email addressess send email thru my server.  - Remote users must use username/password to be able to have email relayed thru my email server.  most remote clients will be using Outlook Express, a few using Outlook 2000.

Problem:  I can't get it to work right.  I have sasl installed, and have added a dummy user to the database named tom.  He can get pop his email, but he can't send email thru outlook express on an external network.  It comes up prompting for a username and password, but all I get are failures...

here is the error I'm getting in my messages:

Mar 25 10:41:33 mail saslauthd[30740]: do_auth         : auth failure: [user=tom] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

here are the relevant lines in sendmail.mc...

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
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 #
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #

I know I am fairly close to the solution, but I am just doing something simple wrong.  Any help would be most appreciated.

On a side note - I'm also having to come into sendmail's smtp vi port 587 on my client instead of 25, I don't know why but it won't respond on port 25 to external hosts at all.  I know the firewall isn't blocking it, I've checked several times.

Thanks in advance.
Avatar of da99rmd
da99rmd

> On a side note - I'm also having to come into sendmail's smtp vi port 587 on my client instead of 25, I don't know why but it won't respond on port 25 to external hosts at all.

Is this to send mail or to recive mail ?
It would be most helpful to know what Linux you are using.

A common problem on a RedHat or Fedora system with Sendmail is if you fail to remove the localhost security restriction from /etc/mail/sendmail.mc by commenting out the line that reads:

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

after that sendmail.cf must be rebuilt and sendmail restarted. Then check to be sure that Sendmail is listening on the machines IP by trying a 'telnet mail-hostname 25' from another machine on the local LAN. If that works and you get an SMTP welcome banner you know that the mail server and sendmail are listing for connections. Next try the same from an Internet site. If you don't get the banner either your local firewall needs tweaking or your ISP is blocking connections on 25/TCP.

It really isn't a good idea to use saslauthd as a mech if you have Internet users. That limits the authentication method to be PLAIN or LOGIN and thus exposes the user's password to anyone that can sniff the traffic. For security PLAIN & Login should only be used withing an encrypted connection. As far as Sendmail is concerned you can change /usr/lib/sasl/Sendmail.conf to use auxprop instead of saslauthd and create user auth information for each user with saslpasswd2. Then you can tell Sendmail to only offer DIGEST-MD5 or CRAM-MD5. Most modern email clients support those.

The same issue arises with POP or IMAP if you aren't using the  Cyrus or Courier IMAP server. The UW-IMAP only can autheticate against the system passwd/shadow files and that exposes the plaintext password to a sniffer. Cyrus & Courier can be configured to use sasldb via auxprop and be restricted to the secure methods. Otherwise you should only off POP or IMAP via an encrypted connection.
Avatar of navigator010897

ASKER

Well, I'm still having a problem.

I am using Fedora version of redhat.

The daemon setting about 127.0.0.1 I had already taken care of - I am pretty sure right now that there is a firewall somewhere betwee this box and the net that is causing a problem with regard to port 25, so I'll have to deal with that part on monday.

I am still having trouble with the authentication tho for outbound email.

In outlook express, I get the standard:

The message could not be sent because the server rejected the sender's e-mail address. Protocol: SMTP, Server Response: '530 5.7.0 Authentication required', Port: 587, Secure(SSL): No, Server Error: 530, Error Number: 0x800CCC78

I have tried adjusting the Sendmail.conf file - but I could only find it in the sasl2 directory under /usr/lib, not the sasl directory.

Also, do I need to run another daemon for auxprop, or how does it work?

I'm also not sure if I'm sending the correct command line entries to saslpasswd2...

I'm creating a test user with:

saslpasswd2 -c tom

But I am also not sure if sendmail is querying auxprop....
I was wondering if the problem was related to what machines are allowed to relay?  Since we want remote clients to be able to send mail even if they are on different ip addresses, we want to make sure relaying is restricted to user/pw authentication..  
Typo on my part... I meant /usr/lib/sasl2/Sendmail.conf. No extra daemon is needed for auxprop, just the SASL2 db that has had entries created with saslpasswd2.

For the moment I'd suggest switching sendmail back to the standard SMTP port. I'm not sure if using 587 might create a problem or not. Since you can't at the moment authenticate a remote user, it is of little importance that something is blocking inbound connections on port 25. Andsince that has to be solved before you can receive mail from Internet sites I see no reason to even try 587.

One this that can cause problems with SMTP AUTH is if the networking config doesn't follow Unix, as opposed to RedHat conventions. The hostname of the machine must be the FQDN and be set that way in /etc/sysconfig/network (HOSTNAME=my-mail.my-domain.tld) and the hosts file has to look like:

127.0.0.1         localhost.localdomain localhost
123.4.5.6         my-mail.my-domain.tld  my-mail

The hostname can't change after sendmail starts or there'll be problems. You can check to see that sendmail is using the correct hostname by 'telnet localhost 25' and noting what it claims its hostname is. Typing "HELO my-mail.my-domain.tld" will show you what opetions, including the list of AUTH methods, that you sendmail is offering. After verifying the hostname that sendmail is useing is correct check the SASL DB for the correct auth info by executing "sasldblistusers". You should see "user@my-mail.mydomain.tld: userPassword" entries. If the hostname in the sasldblistusers2 output doesn't match the hostname sendmail is using you won't be able to authenticate.

It won't hurt and may help to make /etc/sasldb be owned by root, group mail to ensure that Sendmail can read the sasldb.
Ok, I found my mistake on the port 25.

I am currently working from home on my own t1, and my firewall with regard to this particular computer blocks port 25 traffic to all but one specific server to handle my email, I changed it to access this other server, and that solved that problem.

I have new data though with regard to my problem - it's almost appearing as if it isn't authenticating - it is just rejecting to relay based upon my IP address - which in most cases would be fine for security, but I am needing it to pay attention to the authenticated username / password for relaying.    The error from an OE client looks like now...

Protocol: SMTP, Server Response: '550 5.7.1 <tony@anotherdomain.tld>... Relaying denied. IP name lookup failed [65.171.152.134]', Port: 25, Secure(SSL): No, Server Error: 550, Error Number: 0x800CCC79

I don't see why it won't authenticate.  Here is what is showing in my maillog...

Mar 27 18:27:11 mail sendmail[2860]: i2S0RBXr002860: ruleset=check_rcpt, arg1=<t
ony@anotherdomain.tld>, relay=[65.171.152.134], reject=550 5.7.1 <tony@anotherdomain.tld>... Relaying denied. IP name lookup failed [65.171.152.134]
Mar 27 18:27:11 mail sendmail[2860]: i2S0RBXr002860: from=<tom@mydomain.tld>, size=
0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[65.171.152.134]

It doesn't seem to test at all.
ASKER CERTIFIED SOLUTION
Avatar of jlevie
jlevie

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
omg, it just sent.

The problem was with:
define(`confAUTH_OPTIONS', `A p')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

I changed it to:

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

Thank you much, I knew it had to be something simple I was overlooking.

The problem was that your Outlook client can only do LOGIN as an auth method and you'd explicity told Sendmail not to offer either of the insecure methods (PLAIN & LOGIN) unless the connection was made using a TLS encrypted session.
Wierd, I figured having login using secure password authentication checked would make it use some sort of encryption....  well, that's annoying.  I'm testing the system with OE 6.x you'd think it would offer encryption capabilities.
The server has to be configured for TLS encryption before an Out-of-luck client can use a secure session, as far as I know since it only supports the LOGIN method. Other email clients (Evolution, recent versions of Mozilla or Netscape) can use DIGEST-MD5 or CRAM-MD5 for secure authentication outside of a TLS data stream.
Yeah, I'd do that if I could - unfortunately, I don't have enough swing with those in power to get them to change email client ;)

I was working on the TLS encryption, unfortunately, I might have to pull teeth to get a little funding to get a signed cert - doing our own signing certificate wouldn't be a big deal to me, but it seems that the client keeps complaining about it.  I tried adding the CA cert to the client trusted root certs, but it still complained (something along the lines of the names not matching, not sure if I generated the certificate wrong, or I imported the wrong file into the trusted certs DB).

I've never tried to use a self-signed cert with Sendmail, but I don't see why it wouldn't work if it was correctly generated. Whether an m$ client will accept it is another issue. If you poke around on the OpenSSL site there's a couple of tools that can be used to create a self-signed root CA and certs generated from fom it.